tagging releases

[Jensen, Aaron]

> My release process currently includes

> 1) Updating the release version number in manifest(s)
> 2) Tagging the release

> This results in two consecutive changesets which essentially say the same thing:

> 1) Update manifest to 12.6
> 2) Tag 12.6

> How do others do this? Is there a better way which doesn't clutter the change log?

We've resorted to using local tags. Because creating non-local tags creates a new revision, we had trouble reliably synchronizing that tag with the central repository (i.e. it would work most of the time, but when synchronization fails, builds stop working and requires manual intervention). At some point, we'll move to storing tags in some external system or create some process for converting the local tags to more permanent tags. In my experience, Mercurial's tag system isn't automatable from a configuration management perspective, unless your build server and central Mercurial server are using the same repositories (i.e people push to and pull from the same repository your build server uses when tagging).

We've also updated our build scripts to short-circuit builds if the current revision has already built successfully. We just look for a version tag on the current revision, and if we find one, stop the build with a friendly "This revision already built successfully." message.