We are trying to implement a branch model in Mercurial.
We have read the “Successful GIT branching model” and I proposed another, based on branched version numbers.
Then I ended accepting the model with 2 long lived branches, development and releases.
One thing I like about it is the possibility to do “nightly builds”, but I am concerned about how to plan major features for versions.
How is this “development” branch supposed to work? Should get fixes here as fast as I can, but only merge features whenever I want? How do you do this?
I want to plan like this:
Version 1.3: CKEditor + Vote Comments
Version 1.4: Delete and restore comments
And I want this to be in the roadmap of Redmine, which means belonging to a version number before the feature is fully programmed. Mostly because I want to show me (customers in the future) that there is indeed a plan.
Features should be merged into the development branch whenever they are ready. This should happen as soon as possible in order to keep all branches fairly consistent, which reduces merge conflicts. Once merged, feature branches can be deleted. Big features can be split into a number of smaller features. Long-running feature branches can be kept in sync by periodically merging the development branch into feature branches.
A release could be made whenever you have added a new user-visible feature, or when all planned features for the next release have been merged into the development branch, depending on your release model. This lends itself very well to agile-ish approaches where you decide on the next handful of features for the next near-future release. Once you’ve shipped, you re-evaluate priorities and determine the next set of features.
If you do have a roadmap that reaches further into the future than the next release, this does not impact a Git-Flow like branching model: you complete the features for the first milestone, then release it. You complete the features for the second milestone, then release it. If you complete features planned for the second milestone before the first milestone has shipped, these features will be present in the first release. E.g. browser vendors do this all the time with experimental features that are not activated by default.
1