How to use mercurial for release management?

Question

This is a cousin question with my earlier question of \"How to manage concurrent development with mercurial\", which covers individual developer workflow. The answer to this

Answer 1

I'm in the process of re-designing our workflow for release. So I've found this question. I've decided to wrote my experience. For what it's worth ...

---

For development, we are using something that seems to be variation of what you call the stable/default workflow (of course everything goes through commands that enforce the workflow, I call them myw thereafter) :

• we have a central server which holds all of our repositories
• we have a central stable clone per project on this server
• we have a central dev clone per project which is a clone of stable on this server
• initially, one can myw create theproject which create the stable/dev clones for theproject on the server and that locally (on the developer computer)
• when someone has to develop a new feature he can myw clone theproject dev mygreatfeature that :
  • clones the project dev repo on the server as mygreatfeature
  • clones locally the cloned repo mygreatfeature
  • makes lot of useful things like updating hgserver / hudson ci ...
• he can myw fetch dev and myw fetch stable anytime
• when the feature is done he merges it back to his local dev clone, push the merged result on the central dev clone and close the central clone which is archived for a while : myw close theproject mygreatfeature

All of that works great and is pretty smooth. We have preferred clones to named branches as it was simple to really close a feature branch, and at the time the mercurial "named branch" part seemed like "work in progress".

---

The release part of the workflow is presently done basically like that :

• the "release master" fetches from the central dev clone to his local dev clone.
• he fetches from the central stable clone to his local stable clone.
• he fetch from his local stable clone the changes that are in his local dev clone.
• he checks everything, if it is ok, do myw release 1.2.3_RC2 that :
  • tag with 1.2.3_RC2
  • push to the centralized project stable clone.
  • this is in fact a release candidate, that will be tested for a while by our CI server and by our hardcore testers.
• Bug fixes discovered by those tests are fixed on the local stable clone and pushed on the centralized stable clone.
• when its ok, the "release master" do a formal release : myw release 1.2.3

That works pretty well, even if we needs to improve some commands to smooth the process. One of the main drawback it's that's a lot of clones :)

For the management of old releases, we have currently a clone of stable done for each major release. As there is no big need to backport many features, we just have to cherry-pick some really bad bugs with hg transplant (great extension by the way).

---

We have used that for about a year, and we certainly need to improve our homemade commands, especially for the release part :)

The main drawback is that you have to give you/your team some tools to handle it because without them it could be unmanageable, hence our myw homemade set of commands. As usual, the feature branch should not last for too long, or merging can be hard to do. Things like refactoring/renaming has to be done at chosen points, or it will give your team a lot of merging work.

As we are going to have more and more versions to maintain, I'm trying to improve the 'old release but have to support' management part. Reading Bert F comment, I've read this great article. There is good ideas and it is well explained with a really good scheme ! It seems someone has implemented the hg version of his tool git-flow as hg-flow. Something to consider. I like the release and hotfixes branches. And I think that enforcing such workflow with a tool is pretty well mandatory !

my2c