Release Process

This page explains how to do a release of a chameleon project


Before doing a release, you need to check the following aspects

  • Your project has the LICENSE file
  • Your project has a correct NOTICE file and additional LICENSE files.
  • Your project binaries embeds the files mentioned above.
  • All project files have the Chameleon Header
    • For file containing no IP, this can be ignored
  • Your project is in sync with the SVN
  • Nobody else is working on the project
  • No more issues are opened / targeting on this version
  • You can sign artifact with a GPG key maven-gpg-plugin
  • Your GPG key is available from (see appendix A)
  • Your working copy is configured with the good SVN connection (something like svn+ssh://
  • make sure you have all OW2 servers defined in your settings.xml
  • Use Maven 2.0.x (or 2.2.x), as Maven 2.1.x is known to produce wrong gpg pom signatures
  • Your pom file inherits from the latest Chameleon parent pom file
Note: To avoid entering your passphrase every times, you can add the key in the maven settings.xml file:
        <gpg.passphrase> <!-- YOUR KEY PASSPHRASE --> </gpg.passphrase>

Preparing the release

The process is managed by Maven, so to prepare a release just launch (replace login with your forge login):
mvn release:prepare -Dusername=login
  • Answers the questions
  • Wait until completion
This has created a tag in the Chameleon source repository with your code. Check that the Tag in the 'Releases' folder (of the Chameleon SVN) is created correctly.

Staging the release

This step creates the release artifacts that can be reviewed by the Chameleon team. Generates the release artifact with:
mvn -DaltDeploymentRepository=local::default::file:///tmp  release:perform

This commands creates the artifacts in /tmp. Upload those artifacts to a publicly available location and ask the team to check the release. Then send a mail to the Chameleon dev list to ask members to check the release. There is no strong rules about the number of checking. At least one is required.

Checking the release

Checking a release consists in:
  • Checking the MD5 and SHA1 file
  • Checking the GPG signatures
  • Checking that all files contains the Chameleon header
  • Checking the availability and the consistency of the NOTICE file and LICENSE files.
Once checked by at least one member, the release can by deployed.

Deploying the release

To deploy the release, just re-execute the release perform:
mvn release:perform -Dusername=login

Wait a couple of minutes to check the availability of the artifacts on When it's done, also copy the artifacts to the Chameleon download folder by using the Chameleon forge - files - admin - new release and add files.

Then, edit the Downloads page and post a news.

Branch model

If you need to do an hot-fix on an already released module:

  • Copy the released tag to branches with the adequate version number.
  • Update the version number
  • Apply the fix
  • Execute the release process from the branch
  • Be careful to not to alter the version scheme.
We don't recommend branches as we prefer releasing from trunk if possible.


Appendix A - Editing the KEYS files

If you are using a *nix system with a working OpenSSH, GnuPG, and bash you can create and add your own key with the following command:

  1. Create a public/private pair key:
gpg --gen-key
  • When gpg asks for e-mail linked the key you MUST USE A SUSTAINABLE address.
  • When gpg asks for comment linked the key you SHOULD USE "CODE SIGNING KEY".
2. Add the key to type the following command replacing the word e-mail with your email.
(gpg --list-sigs e-mail && gpg --export --armor e-mail) > toadd.key
      scp toadd.key
      ssh "cat toadd.key >> /var/lib/gforge/chroot/home/groups/chameleon/htdocs/dist/KEYS"
3. You are now DONE, but to see the changes on you must wait around 1 hour.