[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