Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: switches from manual tagging to release:prepare

...

This is necessary to ensure that Nexus is used as the deployment target.

Creating the SVN tag

...

Prepare Your Version Number

A guideline regarding version numbering can be found at http://commons.apache.org/releases/versioning.html - within Commons we reached the following consensus

  • when your release a new major or minor version it comes without point release number, e.g "foo-1.0.jar" or "foo-2.1.jar"
  • when doing a bugfix release your need to add the point release number, e.g "foo-1.0.1.jar" or "foo-2.1.1.jar"

Prepare Your Maven Variables

During the staging process a directory is created on people.apache.org based on the content of the following Maven variables

  • commons.release.version is a duplicate of the pom version
  • commons.rc.version is the current number of your release candidate

That could look like the following snippet taken from commons-exec

No Format

<properties>
  <commons.release.version>1.0.0</commons.release.version>
  <commons.rc.version>RC2</commons.rc.version>
</properties>

Update Your Download Page

The commons-build plugin generates a download page in ./src/site/xdoc/ based on commons.release.version

No Format

mvn commons:download-page

Define Staging Site for Release Candidate

Also ensure that the rc profile will stage the site (rather than update the Commons component website). See bottom of Commons SCXML POM as an example. See COMMONSSITE-26 for background.

No Format

<profiles>
  <profile>
    <id>rc</id>
    <distributionManagement>
      <!-- Cannot define in parent ATM, see COMMONSSITE-26 -->
      <site>
        <id>apache.website</id>
        <name>Apache Commons Release Candidate Staging Site</name>
        <url>${commons.deployment.protocol}://people.apache.org/www/people.apache.org/builds/commons/${commons.componentid}/${commons.release.version}/${commons.rc.version}/site</url>
      </site>
    </distributionManagement>
  </profile>
</profiles>

Prepare Your Assembly Descriptors

If you are declaring/using your own assembly descriptors make sure that they are not using ${version} but ${commons.release.version} - there seems to be an odd bug which results in an incorrectly expanded version string, e.g. commons-exec-2.4.1-src. If in doubt look at ./src/assembly/src.xml

Commit Your Changes

When you followed the instructions you have modified a couple of files by now - commit them now otherwise the release process will fail.

Dry Run Your Maven Release

Check that your poms will not lose content when they are rewritten during the release process.

  • mvn release:prepare -DdryRun=true
  • Diff the original file pom.xml with the one called pom.xml.tag to see if the license or any other info has been removed. This has been known to happen if the starting <project> tag is not on a single line. The only things that should be different between these files are the <version> and <scm> elements. Any other changes, you must backport yourself to the original pom.xml file and commit before proceeding with the release.
  • Remember to do 'mvn release:clean ' before you start the real release process

...

  • .

Deploy the artifacts

Once the code appears to be ready, the Maven artifacts can be deployed:

...