[Releasing] rethinking the branching scheme

[Ziller Eike]

On Feb 24, 2014, at 4:15 PM, Thiago Macieira <thiago.macieira at intel.com> wrote:

> Em seg 24 fev 2014, às 08:30:24, Ziller Eike escreveu:
>>> 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
> 
> I didn't mean it's a prerequisite for branching. I meant that it's a 
> prerequisite for releasing the alpha. So the merging is still required in any 
> case, but we just shifted the requirement forward in time.
> 
> Now, I prefer it where it is because it means there's no way to skip it. 
> There's no temptation to say "it's too broken, we're going to release the 
> alpha anyway" or further delays in the alpha release due to merging failing.

Maybe "must be a prerequisite for branching” weren’t the right words. I try to rephrase:
I disagree with your opinion that it’s important that moving from 5.x to 5.y is a direct fast-forward and that all fixes are present the moment the 5.y branch is created (which would require a merge before branching).
Because, as I tried to say below, I think the action of creating / defining different branches for “stabilizing of what was dev” and “continued feature development” is (or should be) completely separate from the important task of making sure that all fixes actually end up in the release.

>> 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.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> _______________________________________________
> Releasing mailing list
> Releasing at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/releasing

-- 
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