[Releasing] rethinking the branching scheme

[Ziller Eike]

On Feb 22, 2014, at 7:40 PM, Thiago Macieira <thiago.macieira at intel.com> wrote:

> Em sáb 22 fev 2014, às 12:25:56, Oswald Buddenhagen escreveu:
>> real branching:
>> - [write notification mail that we are starting the branching process]
>> - [lock down parent branches]
>> - [wait for integrations on parent branches to succeed or fail]
>> - create child branches (with a script): ~1 minute
>> - clone CI configs (with a script): ~2 minutes (yup, we'd need to put
>>  some effort into it to ensure that it is that painless)
>> - write notification mail that branches were created: ~2 minutes
>> - total time: ~5 minutes
>> 
>> - on top of that, the forward-merging from the previous stable branch
>>  needs to be done and integrated. that delays the release, but is
>>  asynchronous to development.
>> 
>> - [after two days, unlock parent branches]
>> 
>> downmerge "branching":
>> - write notification mail that we are starting the downmerge process
>> - lock down child branches
>> - wait for integrations on child branches to succeed or fail
>> - do forward merges
>> - [lock down parent branches]
>> - wait for integrations on parent branches to succeed
>> - do fast-forwards to child branches
>> - unlock child branches
>> - write notification mail that downmerging was completed
>> - total time: ~5 days (your estimate, probably realistic)
>> 
>> - [after two days, unlock parent branches]
> 
> You didn't end up at the same codebase.
> 
> Please include the merging of 5.x into the newly created 5.y branch in your 
> estimate of the first procedure.
> 
> I think it's important that we put that in the mandatory task list, as it 
> guarantees that moving from 5.x to 5.y is a direct fast-forward too and all 
> fixes are present.

I disagree that it must be a prerequisite for branching. Of course whatever is released must contain all fixes, but that is independent of the action of “creating a branch for the version after the next”. Which I think the branching (or the dev > stable merge) is effectively about:

We want to stabilize whatever is in dev, and we want a branch that can be used for feature development for the version after that.
The process of making sure that the stabilizing Qt version contains everything that is needed for releasing it, is actually independent from “creating a branch for continued feature development”.

The suggested branching scheme does the same as “renaming dev to 5.x (for stabilization), and creating a new dev (for feature development)”. Except that for people that have dev checked out the “renaming” is not done automatically, but actually “git fetch; git checkout 5.x” does exactly that for them. *Stabilizing* the branch then of course includes making sure all fixes from earlier versions are in.

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B