Maven Mercurial Release Process

Question

We have recently switched to Mercurial. After watching this helpful video: http://www.youtube.com/watch?v=-k2vLKOUb8s&noredirect=1

I am trying to implement a release process that allows the following: - maven release to be independent of ongoing dev work - patch released versions and then push the fixes back to dev

So far I have come up with this:

This allows us to do a release against the stable repo while development continues on the dev repo.

The problem I have is with the maven release plugin. If I am releasing 1.0.0-SNAPSHOT, I end up with the following in the stable repo: 1.0.0-SNAPSHOT->1.0.0->1.1.0-SNAPSHOT

Now I can push this back to the dev repo and development will continue on 1.1.0-SNAPSHOT. So far so good.

But what is the best way to manage the 1.0.0 release and subsequent patches? Should I create a branch from the 1.0.0 commit point or another clone? Is there some other way to manage it so a dev doing a 1.0.1 fix can easily apply it and also push the fix back to dev?

Answer 1

Your setup sounds pretty good. I would make a new long-term named branch based on the changeset with the 1.0.0 release. Keep your development on the default branch and create branches for each release.

Here I write the version number in the POM above and below changesets, and the branch name all the way to the left:

          1.0.0-SNAPSHOT    1.0.0    1.1.0-SNAPSHOT
default:  o --- o --- o --- o ------ o --- o --- o --- o --- o --- o
                             \                              /
1.0.x:                        o --- o --- o --- o -------- o --- o --- o
                              1.0.1-SNAPSHOT    1.0.1      1.0.2-SNAPSHOT

So you work happily on version 1.0.0-SNAPSHOT using the default branch. When it's time for a release, the plugin makes a changeset with 1.0.0 and immediately another changeset with 1.1.0-SNAPSHOT, all on the default branch.

You can branch off for 1.0.x releases now or later — doesn't matter. When you do branch of you

$ hg update 1.0.0  # <- this is a tag
$ hg branch 1.0.x
# edit the POM to change version to 1.0.1-SNAPSHOT
$ hg commit -m "Started 1.0.x branch"

Developers can now always use

$ hg update 1.0.x  # <- this is a branch

to get to the latest changeset on that branch, and hg update default to get back to the main line of development. When changesets are committed on the 1.0.x branch, you'll want to merge them back to default so that the bug will also be fixed there:

$ hg update default
$ hg merge 1.0.x
$ hg commit -m "Merge in bugfix-123 from 1.0.x"

The choice between one or two repositories on your server is mostly irrelevant now. You use the named branches to distinguish between stable changesets (they are on 1.0.x) and less stable changesets (they are on default). However, it often makes good sense to keep a repository on the server for each stable release. You can setup jobs in Jenkins or use cronjobs to do

$ cd foo-1.0.x
$ hg pull --branch 1.0.x

at regular intervals so that clones are kept up to date. You can also make some changegroup hooks in the main dev repo like this:

[hooks]
changegroup.1.0.x = hg push --branch 1.0.x ../foo-1.0.x
changegroup.1.1.x = hg push --branch 1.1.x ../foo-1.1.x

Developers will have to wait until the hooks finish, but it should be quick when you just push between local repositories. Use an asynchronous synchronization mechanism (Jenkins, cronjob, ...) if this is a problem.

Answer 2

From a publication workflow perspective, it is best to isolate any hotfix in a dedicated branch (that you can push around from repo to repo) or repo (if you want to avoid 'named branches').