bug#11153: change automake branching policy: dispensing with the 'branch-X.Y' branches in the future

[Peter Rosin]

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