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

[Stefano Lattarini]

On 04/03/2012 12:01 AM, Peter Rosin wrote:
>
> [SNIP]
>
> I'll try to explain what I mean again...
> 
> I think we should do exactly as you describe above.  However, for the
> class of changes that are related to the actual release from maint
>
Changes which, actually, consist just in *bumping a version number* in
NEWS and in the AC_INIT invocation in configure (in our current setup
at least).

> we shouldn't use the maint branch, and therefore we need three branches.
> I.e. we should not commit, to maint, exactly those changes that we do
> not want on master but still want in the maintenance releases.
> E.g. we will *never* want the change bumping the version from 1.12.3 to
> 1.12.4 on master.  Now, if we do not have both maint and branch-1.12,
> we will have to jump through hoops to not get those changes into master
> when we next merge maint into master.
>
No, we will just have a merge conflict on the version number -- that is
very trivial to solve.  I don't think introducing an extra branch just to
avoiding this slight and seldom-occurring annoyance would be warranted.

> I see two alternatives if there is no branch-1.12 (but see below,
> near the end, when I think of a third option with short-lived branches)
> 
> 1. resolve the merge conflicts, and hope that all changes that
>    we don't want on master really do result in conflicts so that
>    we don't neglect to fix them up in the merge.
>
The point is that *we want all the changes of the maintenance branch to
be merged master*.  That is basically what we have today, and it seems
to me it has worked out pretty well (apart from the msvc mess-up, but
that happened *exactly* because we didn't have the maintenance branch
truly merged into master for a while -- causing all sort of useless
conflicts and divergences and confusion).

> 2. merge from maint into master before the release-related commits
>    and then do a dummy merge (--strategy=ours) afterwards so that
>    the changes are ignored when we do a real merge later.  And
>    hope that no real changes have weaseled their way into the "release
>    window" between the pre-release merge and the dummy post-release
>    merge.
>
Again, the only changes a release-related commit should do is to bump
the version number in configure.ac and NEWS; there's hardly a way for
any real change to "weasel its way" into master this way, no?

> I just happen to think those hoops are a worse cure than the disease
> (an extra branch) they are targeting.  I.e., I think that maintenance
> releases should happen from a separate branch from maint, so that
> maint always merges as cleanly as possible into master.  That separate
> branch is branch-x.y.  I fail to see what is wrong with the current
> setup.
>
Basically, we have a dead-weight branch (branch-1.11) whose only
difference from maint is the version number in configure.in (and, at
the moment, some extra differences in NEWS, which are just a further
source of confusion and possible errors).

> So, how do you intend to jump through the hoops described above
> without the extra branch?
>
I don't, because there are no real hoops to jump through IMHO -- more
likely a single step to be climbed up and down once every time we do a
maintenance release (so, once a month at most, counting beta releases
as well).

> I only see one argument for killing the third branch, and that is the
> msvc confusion.  And yes, we did make a mess of it with the msvc branch,
> but we have learned and will not be so easily duped into pulling in
> changes in branch-x.y without going via the maint branch the next time
> we have the urge to merge a topic-branch with code suitable for master
> into a maintenance release.
>
So, if any "meaty" change for the maintenance branch 'branch-X.Y' is to
pass for 'maint' first -- what is the point of having this 'branch-X.Y'?
It's just dead weight.

>> This is basically the situation we have today, but without the extra
>> indirections and possibility of confusion (i.e., another 'msvc'-style
>> mess will be made less likely).
> 
> I think we have learned that lesson, I don't think we will mess up like
> that again.  I therefore do not think it's a valid argument for killing
> the third branch.
>
The real reason I have to want to kill the third branch is that it's
utterly useless with our current git setup.

>
> [SMALL SNIP]
>
>> I snip mostly of the rest of your arguments, now that it is clear
>> I still *want* to have a maint branch.
> 
> I don't agree that it's a maint branch if you include the commits
> related to the release on it.  By doing that, you have a release
> branch that is not suitable for merging into master in the way that
> a maintenance branch would be.
>
I still don't understand why it isn't suitable...  surely not because
we'll have to solve the spurious merge conflict in the version number
once a month, right?

>>> I think it's immensely more clean to have the current dual maint and
>>> branch-1.11 approach for each expected bug-fix series.
>>>
>> Here I don't follow you.  Why are not 'maint' a 'master' enough exactly?
> 
> See above.
> 
>>> When 1.12 is released, maint should probably move along with it
>>>
>> Yes, and a "new" master created, from which 1.13 will be finally derived.
> 
> No, you need never create a new master, that's not a sane view of
> what happens.
>
Let me explain in more details what I meant by "creating a new master branch".
With my proposed setup, just after the (say) 1.12 major release ,you merge
master into maint, bump the version number on both master (to 1.12a) and
maint (to 1.12.1a), re-merge maint into master (fixing the spurious conflict
on the version number), and christen this new state of master as the "new
master branch".

> It's saner to view it as if you branch off whatever you need from master
> to make the major releases.
>
I'd rather follow the example of git.git, which cuts the releases directly
from the 'master' and 'maint' branch:

  $ cd ~/src/git && git log maint

  commit cb2ed324fc917db0b79d7b1f3756575ffa5f70d5
  Author: Junio C Hamano <address@hidden>
  Date:   Mon Apr 2 13:07:58 2012 -0700

      Git 1.7.9.6

      Signed-off-by: Junio C Hamano <address@hidden>

  commit b52ab19d91015ebd6bebc83a82b2c3d64b948b36
  Merge: b8939b2 d387868
  Author: Junio C Hamano <address@hidden>
  Date:   Mon Apr 2 12:56:35 2012 -0700

      Merge branch 'jc/maint-merge-autoedit' into maint

      * jc/maint-merge-autoedit:
        merge: backport GIT_MERGE_AUTOEDIT support

  commit b8939b2b3abaa99c18bf57251cd2828b89ac38c5
  Author: Heiko Voigt <address@hidden>
  Date:   Thu Mar 29 09:21:22 2012 +0200

      string-list: document that string_list_insert() inserts unique strings

      Signed-off-by: Heiko Voigt <address@hidden>
      Signed-off-by: Junio C Hamano <address@hidden>

  commit 8ced9c90a28f6abc80dc5ad4cf7921c2322c0bb0
  Author: Junio C Hamano <address@hidden>
  Date:   Mon Mar 26 12:23:34 2012 -0700

      Git 1.7.9.5

      Signed-off-by: Junio C Hamano <address@hidden>

  ...

>
> [SNIP]
>
>>> I think we have learned not to merge new features past the maintenance
>>> branch (i.e. directly into the release branch)
>>>
>> Huh?  That *exactly* what should happen most of the time!  It's the
>> AM_PROG_AR situation that was an unusual case, in that we didn't want
>> the delay in the 1.12 release to keep this useful and low-risk feature
>> as "vaporware" for even more time -- so we merged it into the
>> maintenance branch.
> 
> No, we merged it into the release branch.  We only merged it into
> the maintenance branch later.
>
Yes, that's what I meant, sorry for the confusion.  But then again, if
we should merge any change in maint before placing it in branch-1.11 (as
we do today, not willing to repeat the msvc error): what is the point of
branch-1.11?

> 
> *time passes*
> 
> Hmmm, do you perhaps mean to create short-lived branches based on
> maint for each release?
>
> [SNIP]
>
This too would be a viable solution, and I indeed thought about it,
but it seems overkill to me.  So no, that's not what I meant, and
you had not misunderstood me.

Regards,
  Stefano