[Development] Branching for Qt 5 repositories

[BRM]

FWIW, +1.

Ben




----- Original Message -----
> From: Hausmann Simon <Simon.Hausmann at digia.com>
> To: Thiago Macieira <thiago.macieira at intel.com>; "development at qt-project.org" <development at qt-project.org>
> Cc: 
> Sent: Friday, September 28, 2012 4:22 AM
> Subject: Re: [Development] Branching for Qt 5 repositories
> 
> 
> Sounds great, especially the branch names. +1
> 
> Simon
> ________________________________________
> From: development-bounces+simon.hausmann=digia.com at qt-project.org 
> [development-bounces+simon.hausmann=digia.com at qt-project.org] on behalf of 
> Thiago Macieira [thiago.macieira at intel.com]
> Sent: Thursday, September 27, 2012 11:46 PM
> To: development at qt-project.org
> Subject: [Development] Branching for Qt 5 repositories
> 
> Hello
> 
> A few weeks ago I met with Lars, João, Sinan, Sergio A., Jędrzej and a few
> others and we discussed the branching for the Qt 5 repositories. This,
> therefore, does not apply to Qt 4, which shall remain as it is. It does not
> apply to Creator either, but it is available for them to adopt it if they want
> to.
> 
> This follows João's 3-branch plan (the Firehose/Leaky Faucet/Dripping bucket
> one), but with more "traditional" branch names.
> 
> They are:
> - dev: unfrozen branch, containing alpha-quality[*] code that is ready to go
>    into beta testing at any time
> - stable: feature-frozen branch, containing beta-quality or better code
> - release: deep-frozen branch, for which only the release team should
>    approve changes, containing code about to be released
> 
> [*] alpha quality is feature complete, working, documented, tested, etc.
> 
> Note that there is no "master" branch any more. In addition, the 
> default
> branch  (the one that gets checked out on a new clone) will be either stable
> or release, but definitely not dev. The intention is that new developers who
> clone Qt repositories for the first time are presented with a stable codebase
> they can begin working on, bugfixing and even developing new features for.
> 
> Here's the transition plan:
> 
> 1) [transition1.png] First, we'll branch dev from master. Master will be
> regularly merged into dev, as the current submissions in Gerrit are drained.
> New submissions should go straight into dev. Once the master branch is drained
> of reviews, it will be closed.
> 
> 2) [transition2.png] The stable branch will branch off from dev. At this point,
> dev becomes unfrozen again, accepting new features for Qt 5.1. At a later date
> (or very soon after), releases is branched off from stable.
> 
> Note that the timing of 1 and 2 can be anything. In particular, it is probably
> a good idea to unfreeze dev *before* master is closed. That way, current WIP
> 5.1 reviews in Gerrit can be submitted, instead of abandoned and re-pushed
> into dev later.
> 
> For the Qt 5.0 release, we will release from the correct branch (releases).
> 
> Timing-wise, we would like to see the dev branch open in mid-October. If the
> 5.1 merge window is 6 months, this would put the 5.1 feature freeze in
> April/2013.
> 
> Here's how the "permanent regime" will be:
> 
> 1) all three branches are permanent. They are never deleted. Only the versions
> that they target change.
> 
> 2) [permanent1.png] all bugfixes go into the "most frozen" branch that 
> they are
> relevant for, including new features (which of course go into dev). The
> branches are periodically merged, using the CI, from "most frozen" to 
> "least
> frozen".
> 
> 3) [permanent2.png] features trickle down along with version numbers. The Qt
> Project is the only entity allowed to assign Qt version numbers. Note that are
> always working on at least two minor versions at the same time, sometimes
> three. The feature freeze for a given release is when dev is merged into
> stable.
> Also note how the release names match the state of the branch: alpha from
> dev, beta from stable, releases from releases.
> 
> 4) we'll follow a hybrid time- and quality-based schedule:
> - time-based: time between feature freezes (e.g., 6 months)
> - quality-based: maturation of a dot-oh release
> - hybrid: patch releases, should be released timely (e.g. every 2 months),
>    but never in worse quality than a previous release
>    [in mid-Qt 4 times, we used to release patch-level releases every 6-8 weeks
>    and it usually took us 1 week from start to finish]
> 
> The period between feature freezes should be 6 months in the long-term. In the
> short term, it might be slightly less or slightly more, if the Qt Project
> wishes to, in order to align our releases with our downstreams.
> 
> 5) the Qt Project will not maintain a Qt version before the one currently in
> the release branch. Other parties may provide maintenance if so they wish and
> the Qt Project should welcome those branches in its infrastructure, but the
> branches should not be in the main Qt repositories. Releases made out of
> those branches or others outside of the Qt Project should be clearly marked
> and should avoid taking confusing numbering. For example, a release could be
> the last official Qt version plus the number of commits applied on top, plus the
> company's name. (e.g., 5.2.2-digia-125)
> 
> 6) the exception to the above are security or very critical fixes, which may be
> applied to previous releases, directly on top of an existing tag and
> triggering a new release. That is, if it's relevant enough that everyone
> should update, then there's no reason not to make that a Qt release. For
> example, with 4.7 now and the security fix that was released today, we should
> make a new Qt 4.7 release immediately and tag.
> 
> Thiago, reviewed by João
> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>      Intel Sweden AB - Registration Number: 556189-6027
>      Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>