Releasing
This page documents the OPS4J release process for those OPS4J members that are able to release OPS4J artifacts, such as Alin Dreghiciu, Niclas Hedhman, Toni Menzel, Harald Wellmann and others.
Prerequisites
The OPS4J release process is based on the Maven Release Plugin and Sonatype OSS Repository Hosting which enables us to push all OPS4J artifacts to Maven Central. You need to sign up with Sonatype, read their Usage Guide and get familiar with the Maven Release Plugin before doing your first release.
After signing up, create a ticket in OSSRH JIRA to have your account added to the org.ops4j group to get permissions for the org.ops4j staging repositories.
Then you need to generate a GPG key and set up your GPG passphrase and your Sonatype credentials in your Maven settings.xml
. See Appendix B and Appendix C for details.
Before releasing
Before starting the release process ensure that:
- Your Git workspace has no uncommitted changes.
- There are no snapshot dependencies in the project to be released
Ensure that your main project pom inherits from OPS4J master pom, at least version 4.0.0:
<parent> <groupId>org.ops4j</groupId> <artifactId>master</artifactId> <version>4.2.0</version> </parent>
Your main pom project defines an <scm/> section as below, replacing
PROJECT
by your actual project name.<scm> <connection>scm:git:git@github.com:ops4j/PROJECT.git</connection> <developerConnection>scm:git:git@github.com:ops4j/PROJECT.git</developerConnection> <url>http://github.com/ops4j/PROJECT/tree/master</url> </scm>
- Make sure your shell can push to GitHub without password prompts, see Appendix D.
There used to be another master POM org.ops4j.pax:master
for Pax projects which is now obsolete as all definitions in org.ops4j:master
apply to Pax and non-Pax projects alike.
Prepare the release
From a command line run the following:
mvn release:prepare
Perform the release
From a command line run the following:
mvn release:perform
Once you are familiar with this procedure, you can combine prepare
and perform
in one step:
mvn release:prepare release:perform
Doing the two steps separately may help you to troubleshoot problems and rollback.
Troubleshooting
If the release builds fails, you'll have to revert to a pre-release state before trying again. mvn release:rollback
or mvn release:clean
may help sometimes, but not always.
Make sure that all POMs have SNAPSHOT
versions and that the release tag is not set in your Git repository. Use git tag -d myproject-1.2.3
to delete the tag if needed. If the tag has already been pushed to GitHub, use git push origin :refs/tags/myproject-1.2.3
to delete the remote tag after deleting it locally.
Push to Maven Central
The master POM includes the nexus-staging-maven-plugin
which is configured to close the staging repository on Sonatype OSS Nexus automatically. It will not automatically release the staging repository, to give you and others a chance to test the staged release before publishing it.
To push the released artifacts to Maven Central, run the following commands:
cd target/checkout mvn nexus-staging:release
A cron job will push the artifacts to Maven Central within a few hours.
Alternatively, you can log in to Sonatype OSS Nexus to release or to drop the staging repository interactively.
Jira
In the admin section of the released project use the "Release" button to mark the version as released and create the next version. Then close all issues related to just released version using a comment as "Released under x.y".
Change log
Create a change log in the Confluence wiki space of your project. Here is an example from Pax Web. You can include an auto-generated JIRA report of all issues closed for the given releases using the {jiraissues
} macro.
Blog entry
Create a Confluence blog entry announcing the release. The announcement should explain the release highlights and a may include a link to change log created in the step above.
Here is an example from Pax Exam.
Make sure to add the labels release
and <project name>
. This will make your blog entry appear on the OPS4J overview page and on the project homepage by means of a Confluence macro. Check the Pax Exam homepage for an example.
Release announcement
Send a release announcement to ops4j-announcement@googlegroups.com and ops4j@googlegroups.com.
Appendix A: Maven Profiles
As of org.ops4j:master:3.0.0, you no longer need to enable specific Maven profiles for a release.
Appendix B: Authentication
While deploying the artifacts to the specified repositories Maven will use credentials specified in ~/.m2/settings.xml
.
Sonatype Nexus authentication
To deploy to Sonatype repositories you will need an account for which you will get an name/password pair. If you do not have an account, sign up with [Sonatype JIRA|JIRA task] and create an issue to have your account added to the org.ops4j.* group.
The JIRA credentials also given you access to the OSSRH Nexus web interface.
Add these credentials to your settings.xml
:
<settings> <servers> <server> <id>ossrh</id> <username> <!-- your user --> </username> <password> <!-- your password --> </password> </server> </servers> </settings>
Appendix C: Signing key
We are using GnuPG for signing the artifacts via Maven gpg plugin, this is a requirement of the Sonatype OSS release process.
Generate the private/public key pair
On *nix run the code below and follow the instructions:
gpg --gen-key
We suggest that:
- when gpg asks for e-mail linked to the key you should use the e-mail that you use on the mailing lists
- when gpg asks for comment linked to the key you should use "CODE SIGNING KEY"
If gpg --gen-key
appears to hang and complains about missing entropy, open another shell on the same machine and run some disk-bound command like ls -lR /
.
Specify your GPG passphrase
At some point in a release build, GPG requires your passphrase, prompting for it on the command line by default. To avoid this prompt, define the following profile in your Maven installation settings $MAVEN_HOME/conf/settings.xml
:
<settings> ... <profiles> <profile> <!-- Do not change this profile ID --> <id>sonatype-oss-release</id> <properties> <gpg.passphrase> <!-- your key passphrase --> </gpg.passphrase> </properties> </profile> </profiles> ... </settings>
Make sure to include this profile in your Maven installation settings, not in the user settings under ~/.m2
. This is because the Maven Release plugin disables all profiles from user settings.
Note that you can also provide the pass phrase via command line:
mvn release:perform -Darguments=-Dgpg.passphrase=YOURPASSPHRASE
Appendix D: GitHub access
If your Git workspace is configured to use SSH, make sure that you have an ssh-agent
running and call
ssh-add
in your shell before running the Maven Release plugin to avoid prompts during the release process.
Alternatively, if you use HTTPS authentication, specify your credentials via properties when running the Maven Commands:
mvn ... -Dusername=... -Dpassword=... release:perform