-2

We have following requirement when it comes to bussiness process concerning introducing new features to a stable branch.
We have a stable line which gets delivered to our clients. Also we have a development line where we develop new features. Sometimes, we decide that we need to introduce some developed features to a stable release line. Not all, but some of them. How to organize branches (we're using mercurial) so we can cherry pick features we want to apply to stable branch?
On the other side we need to have a branch where we'll have all features integrated into one branch, call it dev branch (which was derived from stable branch).

One of the ideas is to have a stable branch, dev branch (which was derived at one time from stable) and a separate branches for each feature.
Bugs are resolved on the stable branch and from time to time, changes are pulled to other branches (dev and feature ones). Once a decision, of integrating a particular feature to a stable branch, is made, then only a given feature branch is merged with the stable one. Also, feature branches are from time to time pulled on dev branch (which serves to integrate all features that are being developed).

dragan.stepanovic
  • 2,955
  • 8
  • 37
  • 66
  • Assuming you have to go through a testing phase for a change to be considered 'stable', you wont be able to make bugfixes directly on stable and consider it stable, unless you are testing potential fixes on a build made on a dev machine, before publishing to your shared repo. – Kindread Oct 03 '14 at 20:49
  • yap, bug fixes are tested on a build made on dev machine, but for a moment forget about the name of the stable branch, I've just called it that way as an example. – dragan.stepanovic Oct 06 '14 at 00:50
  • My answer below would still apply, but you can forgo the maintenance branches, although for fixes that take longer than a couple days I would still use bookmarks at least. – Kindread Oct 06 '14 at 05:03

1 Answers1

0

Your potential solution would work, and is fairly similar to GitFlow, which can easily be applied to mercurial.

Master would be your stable branch ( presumably 'default' ), and you are fore-going the release branch, which may be a good or bad idea depending on your development/testing process. Either way, it would be a good idea to tag releases.

Rather than merging your feature branches periodically into your dev branch, you can merge only completed features into dev, and then propogate them to your other active feature branches. This gives you the flexibility to release early with completed features if your priorities change ( after completing your integration tests of course ). If you periodically merged incomplete features into the dev branch, you would have difficulty finding a safe release point if it is suddenly decided an already completed feature needs to be released asap. You still have the option of merging a feature branch directly into another feature branch if you are particularly wary of integration issues with them and want to catch them early.

Using hotfix/maintenance branches, as outlined in Gitflow, would allow you to maintain the sanctity of your 'stable' branch. You could either branch for each individual fix, merging it back in and closing the branch when done, or keep an ongoing maintenance branch, which would have to be kept in sync with Stable. I prefer the flexibility of branching for each fix.

Also, for the short term branches, for example small features or hotfixes, you might consider using Bookmarks, but this depends on how you feel about change history.

Kindread
  • 926
  • 4
  • 12