[Releasing] rethinking the branching scheme

[Oswald Buddenhagen]

On Thu, Feb 20, 2014 at 12:17:14PM -0800, Thiago Macieira wrote:
> Em qui 20 fev 2014, às 19:22:30, Oswald Buddenhagen escreveu:
> > ehh, no.
> > the problem with creating old/ branches is that one has to find the last
> > sha1 before a downmerge. this would be a non-issue if created a new
> > branch for every release instead of continuously recycling the same
> > branches.
> 
> Finding it is not difficult, if we freeze stable before the merge. Freeze it for 
> 5 days if necessary.
> 
> Steps are (D = feature freeze date):
> 
> * D - 7 days: put up warnings in Gerrit that stable is freezing & send email 
>   to announce list
> * 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.
ignoring the other arguments, that is.
and that stable once being the target and once the source, it being a
pain to set up the gerrit permissions to make the lock effective.

> * Between D - 5 days and D: merge stable upwards to dev
> * D to D + 2 days: fast-forward stable to dev
> 	* and unfreeze stable
> 	* remove notices and send email to announce list
> 	* bump version number in dev
> 

On Thu, Feb 20, 2014 at 01:15:02PM -0800, Thiago Macieira wrote:
> Em qui 20 fev 2014, às 12:17:14, Thiago Macieira escreveu:
> > * D to D + 2 days: fast-forward stable to dev
> 
> To be clear here: "fast-forward stable to dev" means
> 
>       git checkout stable
>       git merge --ff-only dev
> 
> A.k.a.:
> 
>       git push gerrit dev:stable
> 
> 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.