mvn release:branch -DbranchName=releases/tools/1.0
Releasing the tools
The tools contain all the parts we need to actually build our presentations.
They currently consist of 3 parts:
content-parent-resourceswhich contain all the static resources we need to build the presentations.
content-parent-pomwhich is pom, when used as parent for a presentation, will make sure all is configured correcty, dramatically reducing the amount of configuration needed.
content-archetypewhich is a maven archetype which can be used to generate a new presentation module based on the current
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:
|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
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.
This now will:
Checkout the tag into the "target/checkout" directory
mvn deploybuild in this clean checkout with enabled
In this build - due to the
apache-releaseprofile - will also build
javadocjars, create a source distribution
Create md5 hashes for all artifacts
Sign all artifacts with your GPG Keys
Deploy everything to the
Apache NexusStaging 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)
Staging Repositoriesin the
Build Promotionmenu on the left-hand side (If you can’t see it, you’ve probably not logged in)
Use the search box of the
Staging Repositoriestab and search for "training" (It will probably have only one)
Select the entry.
Click on the
Enter a meaningful message and click
Refreshbutton in the tab untill the column
URLdisplayed 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
| Be sure to not take the files form the
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: