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

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!


Blog Topics:

Comments