Fork me on GitHub

Creating Releases

This is a how to document for creating Apache Jackrabbit releases. It documents the current release process and needs to be updated as we move forward.

Release planning

Jackrabbit releases are created based on user demand and the availability of fixes and other requested changes. Any committer can declare their plan to cut a release by sending a “Apache Jackrabbit x.y.z release plan” message to the dev@ list. The plan should refer to Jira for the list of fixes to be included in the release and give a rough estimate of the release schedule. It’s OK to revise the plan if needed. Optimally, link to the candidate release notes.

If you’re not a committer, you can send a message to the mailing list asking for a new release to be made. Including the list of specific fixes you need and a short rationale of why you need the release.

Prerequisites for release managers

You need to be a Jackrabbit committer to prepare and perform a release, but anyone is welcome to help test the release candidates and comment on the release plans.

You should have a code signing key that is included in the Jackrabbit KEYS file. See Appendix A at the end of this page for more details.

You also need to tell Maven your Subversion credentials needed for deploying artifacts to the Nexus server at See Appendix B for the required settings.

Release management tasks

  1. Make sure that an appropriate version for the release is entered in Jira and that all the related issues have been resolved.
  2. Create a new version in JIRA for the next release.
  3. Create a RELEASE-NOTES.txt file in the root folder of the project to be released. If such a file already exists, update it for the release. See a previous release notes for examples of what to include. The release note report in Jira is a useful source of required information: Open the JCR Jira or OAK Jira page, click on the release, then on the “Release Notes” button on the top right. Double-check that all version numbers in the updated Release Notes are accurate. When done, commit the file.
  4. Build and deploy the release artifacts with Maven. See below for the exact steps.
  5. Do a sanity check that the staged repository on contains all artifacts (~19 projects for Jackrabbit).
  6. Close the staged repository, giving it a meaningful name, such as “Apache Jackrabbit 2.x.y RC”
  7. Upload the artifacts to (instructions at the end of the build)

    cd /path/to/jackrabbit-dev
    scp -r /path/to/jackrabbit/target/checkout/target/$version $version
    svn add $version
    svn commit -m "Apache Jackrabbit $version release candidate" $version
  8. Start the vote thread, wait 72 hours. See the vote template generated by the Maven build.

  9. Mark the version as released in Jira: Jira Project Home -> Project Summary -> Administer Project. Under Versions, click <More>. You’ll see all the defined project versions. From the settings menu, choose ‘Release’ on the version.
  10. If the vote fails (easy case first) remove the tag from svn, drop the staged repository and revert the version release in Jira- done
  11. If the vote is successful

    • close the vote by publishing the results
    • copy the release candidate from dev/jackrabbit to release/jackrabbit in careful to properly set the version variable!!!
    [ "x$version" = "x" ] || svn move -m "Apache Jackrabbit $version" \$version \$version
    • delete any older releases from the same branch (they’re automatically archived)
    • release the staged repository for synchronization to Maven central.
    • close all the issues included in the release: Jira Project Home -> Change Log -> Choose the released version. From the issue list you have the option to bulk update all of the included issues. Just ‘Transition Issues’ from ‘Resolved’ to ‘Closed’ and you are done!
  12. Update the Jackrabbit web site to point to the new release.

    2. (while doing so please a) remove obsoleted entries, and b) move new entries for Jackrabbit and/or Oak to the top)
  13. Send the release announcement once the web site and download mirrors have been synced. Please note the announce mails needs to be sent from an address.
  14. If the release was a Jackrabbit release used in Oak, make sure to also update the dependency in oak-parent/pom.xml (example: OAK-4743 - the current mapping is Jackrabbit 2.15 -> Oak trunk, Jackrabbit 2.14 -> Oak 1.6, Jackrabbit 2.12 -> Oak 1.4 and 1.2, Jackrabbit 2.8 -> Oak 1.0)
  15. If the release was a stable release for which we publish API docs (such as Jackrabbit), consider updating the live site ( - when producing the API docs, use a checkout of the actual release, specify an English locale (-Dlocale=en) and try to pick the right JDK version to minimize changes over the previously checked in docs).

Steps to build the release artifacts

The release is built using the Maven release plugin (if your platform is Windows with Cygwin, see Appendix C). See the Performing a Maven Project Release guide for more details. Make sure you have added the pgp key information in you maven settings file, especially if you have more than one key installed locally. See Appendix B for the details.

In case you don’t feel comfortable to keep the passwords in the file ~/.m2/settings.xml forever, you need to set it now temporarily.

There have been some problems with certain combinations of Java and Maven versions. A known combinations where releasing was successful is Java 7 with Maven 3.2.2. In case you get an exception “Proxy Error” in the release:perform, see the Apache Services Status Page, however it has been reported that the status page is not always accurate. In case you get an error with respect to API incompatibilities, try with an older Maven version or enforce use of a newer release plugin, such as with mvn org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare.

  1. Execute mvn release:prepare. This will update the POM files and tag the release in svn.
  2. Execute mvn release:perform. This will build the tagged release and deploy the artifacts to a staging repository on The non-Maven release artifacts are automatically deployed to your home directory on You only need to add the keyname if you have multiple keys and the code signing keys is not your default key.

After this is done, you can remove the passwords from the file ~/.m2/settings.xml if you don’t want to keep it there.

Appendix A: Create and add your key to the Jackrabbit KEYS file

Follow these instructions to generate your code signing key and to add it to the Jackrabbit KEYS file.

  1. Generate a code signing key using your address as the email and “CODE SIGNING KEY” as the comment. Also make sure it has been sent to a public key server.
  2. The Jackrabbit KEYS file is managed in To modify the file, first checkout the dist directory:

    svn checkout
  3. See instructions on how to append your key to the file (or, as an alternative, the beginning of the KEYS file).

  4. Commit the change using:

    svn commit -m "Add code signing key" KEYS
  5. See the changes on (you may need to wait a few minutes).

You can (but don’t need to) get your key linked to the Apache web of trust. Once other people have signed your key, you can update the KEYS file with the signatures you’ve received.

Appendix B: Maven settings

You need to change the ~/.m2/settings.xml file as follows. PGP key id: this is the second part of your key in the KEYS file. For example, this is “F07CA77B” if the first line of your key in the KEYS file is “pub 4096R/F07CA77B 2014-07-31”. In case you are not comfortable to keep passwords and key passphrases in human readable files, you can add them just before doing the release, and remove them just after the release. Instead of using the “gpg.passphrase” tag, you can try using <gpg.executable>gpg2</gpg.executable> (this should prompt you for the passphrase). For the server svn passwords, you could use the Maven password encryption.

        <gpg.keyname><!-- PGP key id, see above --></gpg.keyname>
        <gpg.passphrase><!-- PGP key passphrase --></gpg.passphrase>
    <!-- To deploy a Jackrabbit snapshot -->
      <username><!-- Apache svn user name --></username>
      <password><!-- Apache svn password --></password>
    <!-- To stage a Jackrabbit release -->
      <username><!-- Apache svn user name --></username>
      <password><!-- Apache svn password --></password>

Appendix C: Cygwin

The Subversion support in the release plugin assumes platform-specific path delimiters, and thus does not work properly if the “svn” executable is the Cygwin version. The easiest workaround for this problem is to install a Windows-native SVN version as well, and to modify the PATH variable for the mvn invocation so that it’s found instead of the Cygwin variant.