[Releasing] rethinking the branching scheme
Thiago Macieira
thiago.macieira at intel.com
Fri Feb 21 22:27:58 CET 2014
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.
With the current scheme, it needs to be done before, as I described.
If we change, assuming 5.x < 5.y:
Either:
lock origin/5.x
git checkout -b 5.y dev
git merge origin/5.x
pass CI
git push gerrit 5.y
or:
git checkout -b 5.y dev
git push gerrit 5.y
lock origin/5.x
git merge origin/5.x
pass CI
Either way the upwards merge is necessary to ensure we've got the latest from
the old stable branch, before the alpha release.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Releasing
mailing list