[Development] Branching 5.0

[Tobias Hunger]

On 28.11.2012 20:47, Knoll Lars wrote:
> 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.

This sounds a a lot like the model proposed by git-flow. How about 
adopting that approach formally so that we can (optionally:-) use the 
git-flow tool to help work with this model?

The branching model:
http://nvie.com/posts/a-successful-git-branching-model/

The tool to support this model:
https://github.com/nvie/gitflow

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. USt-IdNr: DE xxx xxx xxx
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B