A Simple Recipe for Managing Releases with Mercurial
I’ve been using mercurial to manage releases based on this article. After using this method for almost a year, I wanted to share the advantages and disadvantages.
The greatest appeal is that it is super simple. Two branches are all that is required, one called “stable” and the other “default.” The stable branch represents stable code that is ready for release. Use mercurial tags to increment the versions so that you can roll back to a specific release on a whim.
This is the basic workflow:
hg branch >>>default hg ci -m "Making a change to the default branch" hg up stable -C hg merge default hg ci -m "Merging default into stable for release. Bugfix for some issue" hg tag v1.1 hg up default -C hg merge stable hg ci -m "Merging stable back into default.
If you are using a hosted repository, you can now simply pull the latest changes and update to the tag you want. Similarly, you can roll back to a previous tagged version if something get’s messed up. I’ve done it numerous times and getting back to a stable version is as simple as “hg up v1.0”.
If you forget to merge the stable branch back into default there is the possibility that you can have some merge issues around the tags file. The other disadvantage is that you need to tag every release (even bugfixes) to make this system useful. For those who release as often as I try to, this can be tedious. I usually increment my version by a tenth for a feature release and by a hundredth if it’s a bug fix.
Eventually I’m going to move to an automated test and release process where each “build” is unit tested and pushed live. For small projects though, this workflow is rock solid and will save you a lot of anxiety because you can literally fix your shit by rolling back in one line in the terminal.
