[Development] One 'qt' branch to rule 'em all!

Koehne Kai Kai.Koehne at digia.com
Tue Apr 1 13:12:18 CEST 2014


Hi,

We've had now different setups with git branches - in Qt 4 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 Qt 5 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. Anyhow, as discussed on this mailing list in length the current model makes the release process unnecessarily hard ...

I had a discussion with this with a couple of people, including Lars. In the end we realized that both models are too complicated, and we should rather have only one branch. Reality shows that we're working pretty sequential, anyway: Everyone should concentrate right now on Qt 5.3.0, and afterwards on Qt 5.3.1. When Qt 5.3.1 is out we can then decide whether we want to go for Qt 5.3.2, or for Qt 5.4.0 ... It's up to you of course to prepare patches for the next version locally (it's git!), but they should be only submitted when the next version is being created.

Benefits of this approach:
- even less ambiguity about where to put patches
- no need to fork branches
- no need to merge branches
- we encourage focus on the next release
- less variants to be tested in CI

So, here is what we will do:
- create one branch named 'qt' out of current stable
- block any other branches in gerrit
- move on with this branch, and announce the current status of it (open for features, feature freeze, hardening...) on the mailing list

In addition there seems to be a lot of people that want to move back to one git repository for all of Qt, too. Though this can wait until 5.3.0 is out...

If there are no fundamental objections I'd like to see this into action as early as possible, to not risk the 5.3.0 release (i.e. next week Thursday, when we originally planned to merge to release branch).

Kai



More information about the Development mailing list