[Development] Branching 5.0

Knoll Lars Lars.Knoll at digia.com
Wed Nov 28 20:47:47 CET 2012


… this time for real… :)

Qt 5.0 is getting closer, and we're still working to get the final release out before the end of the year. To make this easier and also allow new development towards 5.1 to happen again, we'll branch the qt repositories during this weekend in preparation for the Release Candidate. 

We'll follow the branching proposal that has been discussed and agreed upon on the mailing earlier this year. As discussed there, we will have 3 branches for every repository: dev, stable and release. This weekend we will create dev and stable, release will be be created a bit later (most likely from the RC).

What this means in practise is that there will be two new branches dev and stable for each repository that's part of the Qt 5.0 release. Master will still be there for a (short) transitional period.

We will have the following policies on the branches:

* master:

Transitional only. Will be closed for new pushes once the branches get created. Patches that are already in gerrit can still be staged for around a week to allow everybody to stage their pending changes. Master will then get merged to dev, and we will then completely close master. 

Changes that should go into stable will need to get pushed again to the newly created stable branch and abandoned for master. After master is fully closed all changes that are still pending will need to get pushed to dev or stable again.

Only binary compatible changes are allowed into this branch, as it'll be merged to dev later on.

* dev:

Forms the basis of what will become 5.1. New features are ok to push there, as long as they are complete, tested and documented. 

Please note that although the branch is called dev, larger new features (such as the new ports) should not be developed in this branch. Please use a special development branch for this and push the feature to dev once it's done.

Only binary compatible changes are allowed into this branch.

* stable:

Will become the RC, and we will then create the release branch out of it.

Fully feature frozen. 

We can in theory still do binary and source incompatible changes in this branch until we release 5.0.0, but any such change needs to have an *extremely* good reason and a +2 from me. Until 5.0.0 is out, the main changes into this branch should be doc and packaging fixes as well as bug fixes for major bugs.

Once 5.0.0 is out, this branch keeps forward and backwards compatibility. This means that no new API will be allowed into the branch.


If maintainers for other repositories would like to get the same branches setup, please speak up and tell Sergio and Janne. Both have agreed to do most of the actual work of creating the branches in gerrit and setting up the CI system and a big thanks goes to them already now. 

Cheers,
Lars




More information about the Development mailing list