Branching and Tagging
Here is a diagram of Onyx's branching and tagging strategy.

It is important to note that the version of the HEAD of a branch is constant. For example, the onyx-1.1.x branch will have constant version of 1.1-SNAPSHOT. This is valid because 1.1-SNAPSHOT > 1.1.x for any value of x.
The process is managed by the maven-release-plugin. The procedure is a simple matter of executing a few maven commands.
Creating a Branch
To create a branch, simply execute the following maven command:
Where branchName is the name of the branch to create.
Our SVN structure is a little different than the default structure (i.e.: we create tags under the tags/releases directory). The maven-release-plugin is currently somewhat limited in its support of non-standard SVN structures. The POM file needs to be altered before and after the branch creation.
Before the branch creation, make sure the tagBase element is commented in the top-level POM file:
Once created, the POM needs to be modified to uncomment the tagBase element in the plugin's configuration. This will put releases under the directory we wish to use.
Note that during command execution, the following prompt will appear:
The default answer should be correct. The example prompt above appears when creating the branch onyx-1.4.x. Press Enter to use the default answer.
Tags (releases) are created from maintenance branches, read-on for more information on how to create a release.
Releasing (create a tag) from a Branch
The most common situation is creating a release from a maintenance branch. It involves changing version numbers, tagging the branch and changing the version numbers again (for the next release).
The example procedure will be based on the following scenario:
| State | SVN Directory | POM Version |
|---|---|---|
| Before Release | branches/onyx-1.1.x | 1.1-SNAPSHOT |
| After Release | branches/onyx-1.1.x | 1.1-SNAPSHOT |
| After Release | tags/releases/1.1.0 | 1.1.0 |
This depicts the process of creating the release version 1.1.0 from the maintenance branch. See the diagram above to understand the versioning scheme (it explains why the version is the same before the tag and after the tag).
Steps for Releasing
1. Checkout the branch
2. Execute Maven Goal
3. Answer Questions
| Please note that all default values must NOT be used. We override all of them. |
4. Perform Release
Visit Jenkins and navigate to the appropriate project. (e.g. Onyx 1.5.x) On the left hand side of the page click on Configure. Modify the Script for the Batch task named Release Perform. Change the version number in the script to match the version number of the current release. Click save at the bottom of the page. On the left hand side of the page click on the Task link. Start the Release Perform task by clicking on the green arrow.
Step 3 creates the tag in the codebase. Step 4 builds the artifact from a checked out version of the tag and then deploys these artifacts to the OBiBa repository (maven.obiba.org/maven2). Step 3 may fail in certain circumstances, see issue below
Making JIRA Release
Once the release is complete, the JIRA version must be marked as released. This requires project administration roles and is done through the project administration page.

Maven Release Plugin Issue
There is a bug in the maven release plugin: http://jira.codehaus.org/browse/MRELEASE-409
2 Comments
comments.show.hideOct 12, 2010
Dennis Spathis
The release process is not immune to human error. It would be helpful to include on this page a "Oops! I made a mistake. What do I do now?" section, explaining how to undo different kinds of mistakes (e.g., wrong values provided at user prompts during the mvn release:prepare step).
Oct 12, 2010
Philippe Laflamme
Nothing is ever immune to human errors... humans will always come up with new ways of breaking processes!
Keep in mind that, in the end, the release process is simply editing pom files in batch and making several SVN commits. To "rollback" simply revert to a previous SVN state and redo.