On 2012-04-02 18:13, Stefano Lattarini wrote: > Severity: wishlist > thanks > > Hello Automakers. > > After some real hand-on experience with the current branching policy > of Automake, I'm convinced the presence of the 'branch-X.Y' branches > is just an annoyance and a source of confusion, and that a better policy > would be to simply have a 'maint' branch (where to cut maintenance > releases directly from), a master branch (where maint is to be kept > regularly merged into, and from which the next major release is to be > derived at last), and possibly topic branches (only when needed, and > better if they are short-lived). Maybe we could also re-add the 'next' > branch to serve as common ground for feature merging and testing, but > than can be done in a second time (and only if the need arise). > > When a major release is done, the master branch is to be merged into > the maint branch, and then a "new" master branch created stemming > from the resulting commit.
I think what you are proposing is better described as dropping the maint branch and doing development of features for both the stable series as well as the pending major release directly on the stable branch. When you wish to make a new release you simply make sure you have merged the latest branch-x.y into master, then create a new branch-x.<y+1> or branch-<x+1>.0 from where the current master is and you're done. > WDYT? If you agree, I can apply the change below to HACKING, and > implement the new branching policy starting from the Automke 1.12 > release. Consider what will happen if you don't have maint branches, and need to release security updates for both the 1.11 and 1.12 branches as well as having the security fixes available on master. If you have all the release-related commits as ancestors to the security fix (which you will with this scheme), you will have to resolve inevitable merge conflicts (or cherry-pick, ick). If you instead have a maint branch related to each release series, you should be able to make the real change on the oldest such maintenance branch and then merge it into the more modern maintenance branches, plus master, then merge the respective maintenance branches into the release branches (branch-1.11) before cutting the releases addressing the security problem. I think it's immensely more clean to have the current dual maint and branch-1.11 approach for each expected bug-fix series. When 1.12 is released, maint should probably move along with it and a maint-1.11 can be created when needed, if a security fix is ever needed for the 1.11 series. Hopefully, we will not need a maint-1.11, but such things are as they are... Either that, or you'd need to do dummy merges from branch-x.y into master after the release-related commits just to avoid future merge conflicts, but dummy merges are ugly in my opinion. And branches are cheap. I think we have learned not to merge new features past the maintenance branch (i.e. directly into the release branch) so I'm pretty confident that that particular problem will not resurface even if we do keep the maintenance branch. So, I'm voting for keeping both maint and branch-x.y. Cheers, Peter
