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

[Koehne Kai]

I guess it's obvious by now, but still: This was an April Fools' Day joke.

Kudos goes to Tuukka Turunen for having the original idea.

Kai

> -----Original Message-----
> From: development-bounces+kai.koehne=digia.com at qt-project.org
> [mailto:development-bounces+kai.koehne=digia.com at qt-project.org] On
> Behalf Of Koehne Kai
> Sent: Tuesday, April 01, 2014 1:12 PM
> To: development at qt-project.org
> Subject: [Development] One 'qt' branch to rule 'em all!
> 
> 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development