[Development] Branches and time based releases

Heikkinen Jani Jani.Heikkinen at digia.com
Tue Feb 25 09:59:43 CET 2014


> -----Original Message-----
> From: development-bounces+jani.heikkinen=digia.com at qt-project.org
> [mailto:development-bounces+jani.heikkinen=digia.com at qt-project.org]
> On Behalf Of Thiago Macieira
> Sent: 25. helmikuuta 2014 0:23
> To: development at qt-project.org
> Subject: Re: [Development] Branches and time based releases
> 
> Em seg 24 fev 2014, às 21:11:47, Knoll Lars escreveu:
> > * We have one dev branch for all new development
> 
> I.e., nothing changes. I propose this branch stay named "dev", for clarity of
> purpose, not "master".
> 
> > * We create one branch for each minor release. This branch can be
> created
> > atomically from a ‘known as good’ set of changes in qt5.git
> >
> > * We only do forward merges (5.0 -> 5.1 -> 5.2 -> 5.3 -> ... -> dev). So
> > currently we would go from 5.3 to dev, once 5.4 gets created 5.3 merges
> > into 5.4, 5.4 into dev.
> 
> That's the Creator style, and what we used to do for 4.x.
> 
> > * After creating the branch for a new minor release we do a forward
> merge
> > from the previous branch before creating the alpha. The advantage here is
> > that the forward merge is something we know how to handle (it’s done
> on a
> > rather regular basis), and we then know we have all changes from the
> > previous patch level release in the new release.
> 
> My objection here is that the merging is not the problem. We still need to
> get
> changes through the CI and *that* is currently the problem.
> 
> I still feel we're solving the wrong problem. Or, we can say we're working
> around the problem because really solving it is not within our means right
> now.
> 
> > * The scheme makes it simple and natural to extend the lifetime of a 5.x
> > branch to as long as required. We can simply decide that a certain branch
> > will live longer or have an additional release without having to twist our
> > branching scheme.
> 
> Fair enough.
> 
> > * To create the actual patch level releases (5.x.y), I would propose that
> > we create a short-lived branch from 5.x. That branch gets tested, but no
> > patches get directly committed to it (as opposed to the release branch we
> > have today). Instead I would propose that the release team creates a list
> > of P0 bugs that still have to be fixed before we can fix 5.x.y. Fixes for
> > these bugs get pushed to 5.x and cherry-picked to 5.x.y by the release
> > team. Like that we can control in a better way what goes into the final
> > release and no developer has to deal with a release branch. It should also
> > reduce the risk that other changes go in that again break qt5.git CI or
> > have other negative side effects.
> 
> That's what we've been doing with the "release" branch. But now it has a
> floating name again, like "stable".

Actually this isn't same than we are doing now in release branch. At the moment developers are directly pushing their changes in release branch and somehow expecting those to be in even it has been told only P0, P1 (and really important p2) are allowed to be fixed in release branch. In my opinion this would be really good improvement to our process: We take in only those fixes which has agreed to take in and nothing else. OK, there is a kind of similar system available at the moment (only release team stage changes in release branch) but that isn't really working :( We are taking too much changes in release branch at the moment...


> 
> > * For 5.x.0, the branch point from 5.x should probably be around RC time.
> 
> Yep.
> 
> One more point:
> 
>  * The Git repository's HEAD continues to point to the current "stable"
> release. The fact that we're changing the names of the branches does not
> invalidate the reason why we chose HEAD to point to "stable" back in 2011:
> people should be presented with the most currently relevant yet stable
> release
> available when they clone the repository. And given 2½ years of experience
> on
> this, I can confidently say that this is also the this is the branch that most
> of our developers spend time on.
> 
> That means when we create 5.x from dev, someone needs to go and update
> all the
> Gerrit and Gitorious repositories' HEAD.
> 
> Or maybe we don't have to do it at feature freeze time, but instead a bit
> later. Should we say we flip HEAD at beta time?
> 
> > (In addition gerrit 2.8 will then finally solve this by allowing
> > to retarget a change)
> 
> Any ETA on when we can expect 2.8?
> 
> Though, to be honest, as long as 5.x is not closed, we can and should always
> just push bugfixes to 5.x, even if 5.y (y > x) is already open.
> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


More information about the Development mailing list