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

[Diego Iastrubni]

I agree.

As we move to  a more linear development cycle, we can finally drop
git and update to svn, "where we are going we don't need branches"
anyway.

On Tue, Apr 1, 2014 at 2:12 PM, Koehne Kai <Kai.Koehne at digia.com> wrote:
> 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