[Development] Branches and time based releases

[Thiago Macieira]

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

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