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 question will actually influence the choice for developer workflow.

This is NOT a general "release management best practice" or CI question, as it has been asked many times with good answers, and there's a huge body of literature available to kill time.

I'm only asking for specific ways to use mercurial within the context of release management.

The most obvious and predominant answer would supposedly be stable/default, which is thoroughly covered by the beautiful blog of @Steve Losh, and more concisely in an answer from him. It's simple and effective.

A prominent example of this setup is hg itself. hg uses a few more repositories for active development, but for release management purposes everything seems to be contained in the stable/default branches of the main repo.

The hg setup actually manifests a variation, or rather an extended version, of stable/default: branch clone. I described the process in an answer to a question on named branch vs. multiple repos (with another great answer from @Martin Geisler). What I forgot to mention in my answer is how branch clone works for developer workflow: if you need to fix a bug for a branch, you would hg clone <main repo>#<branch> but not the branch clone, because your changeset will still go back to the main repo and pushed out to branch clone automatically. Of course you can choose not to clone and just hg update <branch> in your main clone, but most arguments for using separate clones (especially the independent build) apply here.

Now back to the question: Are there any other ways that fit different real-world scenarios? For example, a traditional major/minor/patch release cycle with long lapse between releases probably require quite a different workflow than a fast-paced, release-as-you-go web application. Please also comment on the stable/default and branch clone approaches if you feel like.

Since this is almost a survey question, I can only try to accept the "best" answer subjectively. If I can get a few more answers than my developer workflow question, that is.

Thank you for all your inputs!

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