[Development] Setting up time-based releases for the project

[joao.abecasis at nokia.com]

Sven Anderson wrote:
> On 07.08.2012 01:12, Thiago Macieira wrote:
>> On terça-feira, 7 de agosto de 2012 01.00.54, Olivier Goffart wrote:
>>>  ---+--------------------------+---------------------- fire-hose
>>>    / \  /   /   /  /  /  /  / / \  /  /  /  /  /  /
>>>  --+  +-----+--------+--------+  +-----+--------+---- leaky-faucet
>>>   / \  / / / \  / / / \ / /  / \  / / / \ /  / / \
>>>  -+  +-----+  +-----+  +-----+  +-----+  +-----+  +- dripping-bucket
>>>    \        \        \        \        \        \
>>>     5.0.1    5.0.2    5.1.0    5.1.1    5.1.2    5.2.0
>> 
>> I think you're missing the dashes between 5.0.1 and 5.0.2.
>> 
>> dripping-bucket is a rolling branch. To make it fast-forward from one release
>> to the next, it needs to merge them.
> 
> What exactly is the advantage of having "rolling branches" for the
> different stability levels compared to the "specialized" branches for
> each level of version number. Wouldn't it have the same effect but
> clearer semantics if you have a single rolling branch which maintains
> something like alpha level quality, and from that you create a 5.X
> branch that _targets_ beta quality, and after it reached it you start
> creating 5.X.Y branches that target release quality. 5.X+1 is created,
> when the last 5.X.Y has been created and 5.X therefore is dead. This way
> you also have exactly 3 active branches at each time and should be
> isomorph to the solution with three continuously rolling branches, but
> easier to understand in my eyes.

That is essentially what we have been doing until now: a "rolling" master branch that branches off for the minor release cycles and these branches then split again in preparation for (patch) releases (i.e., the release branch).

The new setup being proposed is meant to support a time-based release model. It is inspired on the release model adopted by the Google Chrome team with adaptations to the specifics of the Qt project. A couple of links on Chrome's model:

    http://blog.chromium.org/2010/07/release-early-release-often.html
    http://techcrunch.com/2011/01/11/google-chrome-release-cycle-slideshow/

My proposal, as it stands, is actually very conservative and tries to mimic what we already had. One important difference is the enforcement of a 6-month minor release cycle where we have previously struggled to get it down to 9 months. The setup is supposed to help with that.

While the two setups are very similar, almost isomorphs, they're not exactly so. There are important practical consequences that distinguish the two.

    - Releases happen on a fixed schedule
    - Minor versions have a defined lifetime
    - The number of patch releases is limited by default.

These give predictability and focus to everyone participating on the project. It gives everyone something to align to.

There are other practical consequences. As a developer, you don't have to worry about *when* to do or merge a specific change. You get it up to snuff and decide *where* to apply it (i.e., on which branch).

The fact that the branches roll from release to release means anyone tracking development branches decides how much pain they are willing to take and stay the course. You don't have to wait for the next branch to come along so you can jump to it.

> This might sound more complicated on the first view, but note that also
> leaky-faucet and dripping-bucket would have different quality states
> right after the down-merges until it stabilizes to the targeted quality
> level. This change in quality of the branches is not very transparent
> from the model, which incorrectly suggests that each rolling branch has
> a constant quality level. That's why I would go for specialized branches
> which more obviously traverse different levels of quality. Or more
> generalized: I would prefer a model, that focuses on quality
> _transitions_ rather than quality _levels_, because that's what it's all
> about, right? But maybe I'm missing an important aspect.

The different quality states doesn't change. You can't keep a feature in an isolated development branch indefinitely and expect it gets better over time. At some point changes graduate from where they are and are ready for wider exposure. When you do bring them to a wider audience someone is bound to hit issues you didn't find earlier -- you introduced instability. You also get a chance to progressively fix more issues before graduating to the next level.

"Quality" in a way jumps up and down with the merges, but I don't think we can eliminate these jumps at the moment and in reality they are not introduced by the proposed model.

Taken to the extreme there is typically a difference in quality between a x.y.0 release and a x.y.1, because the former is the first time some features got the widest exposure.

Cheers,


João