Changes in the git branching model of Qt (April fool)

Published Tuesday April 1st, 2014 | by

It’s been a while since Qt adapted git as its revision control system, and we’ve been experimenting with different branching models …

In Qt 4 (qt.git) we followed a scheme with one master branch, which gets forked into minor version branches (e.g. 4.8), which gets forked into patch branches (e.g. 4.8.1) … In the Qt 5 repositories we adopted a model where we had only three branches: dev, stable, release. This was aiming to make it easy for people to participate and submit patches, without having to worry too much about what’s right now the ‘right’ branch to submit.

As it turned out, the dev/stable/release branching model however makes the release process unnecessarily hard, which resulted in a proposal to move back to the original Qt 4 model. After some back and forth the Qt project however seems now to opt for a more radical approach: Changing to a novel, ‘one-branch’ model.

The current proposal on the open development mailing list that so far got unanimous support from developers is to have only one git branch, ‘qt’. This branch is at one point in time in different states, either in ‘dev’ state (allowing new features), ‘stable’ state (hardening), or ‘release’ state (for patch level releases).

The benefits of this approach are:

  • no ambiguity about where to put patches
  • no need to fork branches
  • no need to merge branches
  • ensures focus on the next release
  • less variants to be tested in Qt’s continuous integration system

This approach leverages on the distributed nature of git: You can keep your non-critical commits locally, until the window for new features is open again.

Do you have experience with such a novel ‘one branch model’? Are you aware of any git projects that follow the same model? Let us know!

Did you like this? Share it:

Posted in Git, Qt Project | Tags: , ,

6 comments to Changes in the git branching model of Qt (April fool)

ZeRaler says:

Good 1st April !!

Kai Koehne says:

It was an April Fools’ day joke, indeed :) Though arguably not that obvious if you haven’t seen the discussions on development@qt-project.org about the topic, before …

Interesting. This sounds like one of the earlier models we were using a long time ago when I was release manager of Qt. Note: At that time we were using Perforce and had no continuous integration process.

We abandoned having just one branch that moves between various states, because developers were not aware of what state the branch was currently in. As a result of this, a lot of unnecessary changes were merged in when they shouldn’t. This meant the “release team people” had to spend a lot of time blocking developers in integrating their changes, or reverting changes that got in. This may not be a problem anymore, as there are more gatekeepers before something is integrated, and it’s a lot cheaper for developers to make feature branches these days. Anyways, in my experience it’s difficult to have branches with constantly changing submit policies.

tr3w says:

So it’s basically what the Linux developers do, right?

“At the beginning of each development cycle, the “merge window” is said to be open. At that time, code which is deemed to be sufficiently stable (and which is accepted by the development community) is merged into the mainline kernel.
[...]
The merge window lasts for approximately two weeks. At the end of this time, Linus Torvalds will declare that the window is closed and release the
first of the “rc” kernels. [...] The -rc1 release is the signal that the time to merge new features has passed, and that the time to stabilize the next
kernel has begun.

Over the next six to ten weeks, only patches which fix problems should be submitted to the mainline. On occasion a more significant change will be
allowed, but such occasions are rare [...]. As a general rule, if you miss the merge window for a given feature, the best thing to do is to wait for the next development cycle.

markg85 says:

Looks like an april fools joke :-)

Slartibart says:

Also called the Schrödingers revision model :)

Commenting closed.