Maven Mercurial Release Process

Question

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

I am trying to implement a release process that allows: - the maven release does not depend on the current work of the developers - patches are fixed, and then return the patches to dev

So far I have come up with the following:

This allows us to release against a stable repo, and development continues in the dev repo.

I have a problem with the maven release plugin. If I release 1.0.0-SNAPSHOT, I end up with the following: 1.0.0-SNAPSHOT-> 1.0.0-> 1.1.0-SNAPPER

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

But what is the best way to manage version 1.0.0 and subsequent patches? Should I create a branch from commit point 1.0.0 or another clone? Is there any other way to manage it, so the developer running patch 1.0.1 can easily apply it and push the patch back to dev?

Answer 1

Your setup sounds good. I would make a new long-term named branch based on a set of changes with release 1.0.0. Save the development in the default branch and create branches for each version.

Here I write the version number in POM above and below the changes, and the name of the branch 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 are successfully working on version 1.0.0-SNAPSHOT using the default branch. When it is time for release, the plugin makes a set of changes with 1.0.0 and immediately another set of changes with 1.1.0-SNAPSHOT, all in the default branch.

You can cancel release 1.0.x now or later - it does not matter. When you lead the branch

 $ 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 go to the last set of changes in this thread and hg update default to go back to the main development line. When the variables are fixed in the 1.0.x branches, you will want to merge them back into default so that the error is also fixed there:

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

Choosing between one or two repositories on your server currently does not matter. You use the named branches to distinguish between stable change sets (they are on 1.0.x ) and less stable change sets (they are on default ). However, it often makes sense to store the repository on the server for each stable version. You can set up jobs in Jenkins or use cronjobs to execute

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

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

 [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 are complete, but this should be quick when you just click between local repositories. Use an asynchronous synchronization mechanism (Jenkins, cronjob, ...) if this is a problem.

Answer 2

From the point of view of publishing a workflow, it is better to isolate any fix in a separate branch (which you can move from repo to repo) or repo (if you want to avoid "named branches").