MAY Component Library Release Process¶

• Contenu
• MAY Component Library Release Process
  • General Overview
    • Phases
    • Modules
    • Syntactical Version Numbering
    • Semantic Version Numbering
    • Example
  • Preparing for the Release and Tagging it
    • Updating the POM Files
    • Tagging the Release
  • Deploying the Release on Maven Central
  • Preparing the Next Development Cycle

The component library is a set of projects containing component definitions and implementation to be reused.
They are available through Maven Central for use with Maven.

General Overview¶

Phases¶

Releasing the components implies different phases:

1. Preparing for the release
2. Tagging the release on Mercurial
3. Deploying the release on Maven Central
4. Preparing the next development cycle

All of this is of course fairly automatised using Maven.

Modules¶

See MAY Lib Architecture.

Syntactical Version Numbering¶

The Maven artefact follows the Maven version numbering and it is stored in the pom.xml file of each project.
All are using the 3 digits SemVer system (Major.Minor.Patch).

For non-release (development versions), this is followed by the SNAPSHOT element (Major.Minor.Patch-SNAPSHOT) that is replaced with the compilation time and date on deployment.

Semantic Version Numbering¶

The MAJOR and MINOR number follows the numbering of the MAY plugin as explained on that page.
The PATCH number changes for the rest.

Example¶

For the sake of this guide, we will consider that we are releasing a new version numbered 3.4.0 (and thus we were developing 3.4.0-SNAPSHOT).

Preparing for the Release and Tagging it¶

First, everything must be committed to Mercurial before doing the version update (this can be verified with hg status before).
Let's say we just finished developing the 3.4.0-SNAPSHOT version and want to release the new 3.4.0 version.

Updating the POM Files¶

We must update the POM files to reflect that, but do not touch the MANIFEST files:

$ cd parent
$ mvn versions:set -DnewVersion=3.4.0

This is done from the parent directory and will impact all the modules.

Tagging the Release¶

Now we commit these changes and tag them in Mercurial:

$ hg commit -m "prepare for 3.4.0 release" 
$ hg tag v3.4.0

The commit should only change the POM files, nothing else (this can be verified with hg status before).

Deploying the Release on Maven Central¶

Then, the release has to be deployed to Maven Central:

$ cd ../
$ mvn -P release clean deploy
$ mvn nexus-staging:release

This will clean the sources, compile everything, create packages, install them in the local maven repository and finally deploy the fr.irit.smac.may.speadl.parent and fr.irit.smac.may.speadl modules to Maven Central.

Note that to deploy to Maven Central, it is needed to:

• Have a Sonatype JIRA account linked to this ticket as explained on this page.
• Have a GnuPG key to sign the packages as explained on this page and this page.

The -P release argument is important so that the deployed artefacts have a source and javadoc associated artefact and are signed as needed by Maven Central.
The nexus-staging:release goal must be called to actually accept the deployment and release it on Maven Central: that last phase can also be done trough the Nexus UI.

Preparing the Next Development Cycle¶

Now everything is deployed, we can prepare the next development cycle by increasing the version to a SNAPSHOT one:

$ cd ../parent
$ mvn -DnewVersion=3.4.1-SNAPSHOT

And then, we can commit it and push all the changes we made:

$ hg commit -m "increment to 3.4.1 development version" 
$ hg push