Onyx Branches, Tags and Releases

Skip to end of metadata
Go to start of metadata

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

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Oct 12, 2010

    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).

    1. Oct 12, 2010

      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.