Releasing the tools

The tools contain all the parts we need to actually build our presentations.

They currently consist of 3 parts:

  1. The content-parent-resources which contain all the static resources we need to build the presentations.

  2. The content-parent-pom which is pom, when used as parent for a presentation, will make sure all is configured correcty, dramatically reducing the amount of configuration needed.

  3. The content-archetype which is a maven archetype which can be used to generate a new presentation module based on the current content-parent-pom.

As the parts listed later on in this module listing require the previous ones in the build, we can’t release them all in one go, but have to release them one after the other.

This makes releasing this a little trickier, but in the end it’s a lot simpler for our users.

Creating a release branch

First we need to create a release branch.

Do this the following way:

mvn release:branch -DbranchName=releases/tools/1.0
Note
We’re not using the full version here, as this branch should also contain the bugfix releases and the tags will have the name using the full version. If we used that for the branch itself we would get name collisions during the release.

After this command is done, we will still be on the develop branch. In order to actually start the release, we need to switch to the release branch which was previously created.

git checkout releases/tools/1.0

Doing the release

The release itself is done via the maven-release-plugin.

mvn release:prepare

The plugin will ask some questions.

  • For the new-release version, just hit [Enter] and use the default.

  • For the release tag use: releases/tools/1.0.0 (Or the version used in the question before)

  • For the next development version, again just hit [Enter] and use the default.

The plugin will now:

  • Check if there are any uncommitted files in the release and abort if it finds any.

  • Then it will update the versions of all artifacts in the reactor to the release version.

  • Then check if now any SNAPSHOT version is used and ask to resolve them to release versions if it finds any (If it finds any, this should be addressed as it should not happen)

  • Then it does a build including tests in order to see if it builds with the new version.

  • If this build is ok, it commits the changed poms with the new versions.

  • Then it tags this version

  • Then it changes the versions to the next version

  • Then it commits these changes too

  • Then it pushes the changes

The next step now uses the release tag created in the previous step and builds the release artifacts.

mvn release:perform

This now will:

  • Checkout the tag into the "target/checkout" directory

  • Run a mvn deploy build in this clean checkout with enabled apache-release profile

  • In this build - due to the apache-release profile - will also build source jars, javadoc jars, create a source distribution

  • Create md5 hashes for all artifacts

  • Sign all artifacts with your GPG Keys

  • Deploy everything to the Apache Nexus Staging repository

Last thing you need to do after a successful execution of the release:perform step, is:

  • To log in to Apache’s Nexus at: https://repository.apache.org/#welcome (using your apache credentials)

  • Select Staging Repositories in the Build Promotion menu on the left-hand side (If you can’t see it, you’ve probably not logged in)

  • Use the search box of the Staging Repositories tab and search for "training" (It will probably have only one)

  • Select the entry.

  • Click on the Close button.

  • Enter a meaningful message and click Confirm

  • Hit the Refresh button in the tab untill the column Status changes from open to closed

  • Copy the URL displayed in the details tab for the selected staging repo (In my case: https://repository.apache.org/content/repositories/orgapachetraining-1000)

We’re now done with the preparation of the RC from a Maven perspective.

Next we need to stage the source bundle we will be voting on.

Staging the Release Candidate

What we’ve staged in Nexus is the convenience binaries part of the release, the official release will be the source bundle located in SVN.

These will be located under: https://dist.apache.org/repos/dist/dev/incubator/training/

In our case the tools will be located in a sub-directory tools, so the final path to the RC1 of version 1.0.0 will be: https://dist.apache.org/repos/dist/dev/incubator/training/tools/1.0.0/rc1

I usually prepare a local directory containing all parts and then just import them into SVN in one go.

The local structure for this is then:

/tools/1.0.0/rc1/training-tools-1.0.0-source-release.zip
/tools/1.0.0/rc1/training-tools-1.0.0-source-release.zip.asc
/tools/1.0.0/rc1/training-tools-1.0.0-source-release.zip.sha512
Note
Be sure to not take the files form the target directory directly, but that you use the target/checkout/tools/target versions instead!

Then I just import the 1.0.0 directory using the following command

svn import tools/1.0.0 https://dist.apache.org/repos/dist/dev/incubator/training/tools/1.0.0 -m"Staged RC1 of version 1.0.0 Apache Training tools"

If this is the first time you are releasing something for the Apache Training (incubating) project, be sure to add your PGP key to the KEYS file at: https://dist.apache.org/repos/dist/dev/incubator/training/KEYS

Sending out the VOTE email

Next step is to actually start the vote by sending out the VOTE email.

Here a template for that:

Copyright ©2019-2024 The Apache Software Foundation . All Rights Reserved.

Reflow Maven skin by devacfr.