0

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.

Improve this question

1 Answer 1

Reset to default
1

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.

Improve this answer
1
  • 1
    As an addition: Any "planned version" field in your ticket/issue manager will typically not be reflected in your Hg/Git branches. Such a field is mostly useful to prioritize when to start working on a feature (or how high it is on the product backlog).
    – Bart van Ingen Schenau
    Commented Oct 7, 2014 at 14:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.