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 <[email protected]> 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
> [email protected]
> http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to