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.
