Next focus: PROCESS

[deadalnix]

On Monday, 10 December 2012 at 23:41:25 UTC, Andrei Alexandrescu 
wrote:
> (One piece that has been brought forward is 
> http://nvie.com/posts/a-successful-git-branching-model/ - 
> something to keep in mind.)
>

In this workflow, only one version of the software is produced. 
But we have an extra need : the one to combine language evolution 
(that may break) and long term support. This require some 
adjustment.

Here is how I see things :

New feature are develloped in their own branches.
When a feature is ready, it is included in the dev branch. The 
feature must be rebased on the dev branch to be included.
 From time to time, dev branch is forked. The forked branch only 
receive bug fixes. The second digit of the version is incremented 
(minor). I'll call it stabilization branch.
When the fork branch is stable enough, a tag is made and we have 
a realease. The revision number is incremented.
In the future, more bug fixes can be done in that branch and new 
tag created for new release.

No let's focus on bug fixes. As feature, they are made in their 
own branches. The branch will then be merged in any stabilization 
branch where it make sense and in dev.

master is the highest numbered stabilization branch. By doing so, 
we ensure that user that get sources have a preview of the next 
thing that will be shipped.

I would advice against maintaining a lot of stabilization 
branches as this is more work and too much of them don't bring 
any benefit. 2 to 3 of them is the right amount.

The proposal works well with github, which is a plus considering 
we are using it.