bug#13578: [IMPORTANT] Savannah issues

[Stefano Lattarini]

On 02/27/2013 02:07 PM, Nate Bargmann wrote:
>
> [SNIP]
>
>> Not in this case, as 'master' had several commits lacking in 'maint'.
> 
> Would 'git cherry-pick' have worked? 
>
No, because those commit were to be *dropped* (not added) from master;
the old 'master' containing them was to be renamed to 'next'.

> [SNIP]
> 
> In other words, master contained commits intended for '2.0'+ (for
> instance) that you didn't want in 1.13+, etc.? 
>
Exactly.

> Perhaps a new branch for
> 1.13+ cut from some earlier commit in master and leaving master alone
> would have worked?
>
What would have worked with minimal disruption would have been to keep
the current names until the next major version (maybe just renaming
'branch-1.13.2' to 'fix' or 'micro' *after* the bug-fixing release);
just after the new major release, 'fix', 'maint' and 'master' would
have pointed to the *same* commit, so we could have juggled and
swapped their names without causing any non-ff push.

I thought the disruption of doing the renames right now would have
been negligible anyway, but apparently I was badly wrong in that.

> master would have then been consigned to being for
> new development which isn't what you explicitly stated in the policy
> above.  I have to agree with Miles on the common assumption of the
> master branch in Git as sort of a quasi-stable of the development tree.
>
So we should maybe go (after the next major release) with this naming
scheme for the branches?

  * maint -> for next micro version
  * stable -> for next minor version
  * master -> for next major version

> [SNIP]

Thank,
  Stefano