[Releasing] rethinking the branching scheme

[Oswald Buddenhagen]

On Fri, Feb 21, 2014 at 01:27:58PM -0800, Thiago Macieira wrote:
> Em sex 21 fev 2014, às 16:14:16, Oswald Buddenhagen escreveu:
> > > * D - 5 days: freeze stable
> > > 
> > > 	* create old/5.x branch from stable
> > 
> > well, if you consider a five day lockdown period for the target branch
> > acceptable, then the matter is settled.
> 
> > > Since dev was tested and passed CI, there's no need to retest. This
> > > operation is as atomic as creating a new branch.
> > 
> > pointing out the atomicity of the last step of a five-day process seems
> > a bit absurd to me.
> 
> The fast-forward is atomic. The part that isn't atomic is merging stable into 
> dev. That is required anyway, regardless of branching solution we go for. The 
> only difference is whether the merging is done before or after the branching.
> 
yes, indeed - and it makes the difference between a sane process and
what we have now.

> Either way the upwards merge is necessary to ensure we've got the latest from 
> the old stable branch, before the alpha release.
> 
yes. the merge is in the critical path of the alpha release. we can't
avoid it, and it isn't a big deal.
what makes a world of difference is the merge being in the critical path
of "branching". the difference between "we got a new branch, but
otherwise business as usual" and "all integrations are halted for the
better part of a week". between the start of the release process being
something that happens mostly in the background, and something that is
fairly disruptive to the normal flow (and rather stressful for those
involved) - actually quite the opposite of the intended effect of this
"simple" branching model.