This page describes the steps that a Cayenne Release Manager needs to perform to prepare a release. The specifics of Cayenne release process is that we are publishing both downloadable assemblies and Maven artifacts, so we have to build and publish things twice. Both forms of Cayenne release are also available for evaluation during the vote.

Prerequisites

  • Make sure "apache-releases" repository is configured in ~/.m2/settings.xml and an appropriate password is setup. See this page for details.

Preparing Sources

  • Edit UPGRADE-NOTES.txt if there is anything to add there.
  • Check Sources Compliance with ARAT. ARAT (A Release Audit Tool) is a Java tool written by Robert Burrell Donkin for checking the release files for ASF licensing compliance. To run ARAT, download the jar (we are using version 0.5.1), and run it against unpacked distro (or the release tag), read the report and fix any issues.
cd cayenne
mvn clean
java -jar rat-0.5.1.jar `pwd` > report.txt

Tagging the Repo and Releasing Maven Artifacts

  • Get a trunk SVN checkout of Cayenne. If you are using git for development, SVN checkout is still needed to prepare a release with maven-release-plugin.
svn co https://svn.apache.org/repos/asf/cayenne/main/trunk cayenne
  • Tag the SVN and Create Maven Staging Repository
cd cayenne
mvn release:clean
mvn release:prepare -DpreparationGoals="clean install" -DautoVersionSubmodules=true -Passembly,generic,mac,windows

A problem described in the documentation consistently occurs here ... if you are in Europe: "If you're located in Europe then release:prepare may fail with 'Unable to tag SCM' and ' svn: No such revision X '. Wait 10 seconds and run mvn release:prepare again." It fails indeed, and requires a re-run and continue:

mvn release:perform -P gpg [-Dgpg.keyname=B8AF90BF]

Releasing Downloadable Assemblies

  • Switch to the release tag created above in SVN or Git.
  • Build source package (it will be the basis for the binary packages built in the next steps) :
mvn clean install -Passembly,src
  • Build binary assemblies. Take "assembly/target/cayenne-XXX-src.tar.gz", unpack it somewhere, and perform binary builds from the unpacked directory (NOT FROM SVN OR GIT CHECKOUT). Release manager may skip running unit tests from here, as shown below, although release evaluators should use the src assembly for unit testing and other kinds of testing.
mvn clean install -Passembly,generic -Dmaven.test.skip=true
mvn clean install -Passembly,mac -Dmaven.test.skip=true
mvn clean install -Passembly,windows -Dmaven.test.skip=true

For further details on a general Cayenne build process check this page.

  • Signing assemblies

For more info visit this page. Release manager key must be in the project KEYS file. Signing is a manual procedure not included in the Ant or Maven script. Here is how it might work ("-u" option can be omitted if you have only one GPG key):

gpg --armor -u B8AF90BF --output cayenne-X.X.tar.gz.asc --detach-sig cayenne-X.X.tar.gz
gpg --print-md MD5 cayenne-X.X.tar.gz > cayenne-X.X.tar.gz.md5
  • Assemblies, signature and checksum files are uploaded to the release manager's web directory on people.apache.org.

Voting

  • The vote is started on the dev mailing list.
  • All committers are encouraged to vote on releases. Committer votes will be considered by the PMC (particularly -1 votes will be discussed) when making the final decision, but are not binding.
  • Each PMC member will do the following before voting on a release:
    a. download the artifacts
    b. satisfy themselves that the source matches the appropriate svn tag. This can be done by diffing the source against a recent svn checkout.
    c. satisfy themselves that the Apache licensing requirements are met (this will usually be achieved by ensuring that all notices are in place and verifying that the source matches SVN since all commits to SVN are possible only if the committer has a CLA on file).
    d. satisfy themselves that the binary distribution is sane and passes basic usability tests. For example, that the Cayenne modeler runs and the main jar passes some basic tests.
    e. satisfy themselves that the source passes agreed unit tests (either by running them manually or verifying that Hudson has run those tests against the equivalent source).

Publishing the Release

  • Publish downloadable assemblies:
$ ssh people.apache.org
% cp /path/to/release/artifacts /www/www.apache.org/dist/cayenne/

After the release

  • Tell Jira that the release has been released. Ensure there is another milestone or release target already created for further work, but this was probably already done when a branch was created in preparation for release.
  • Update the DOAP file (held in the Cayenne svn) which will update http://projects.apache.org/projects/cayenne.html automatically
  • Update Freshmeat with new release number (http://freshmeat.net/projects/cayenne/)
  • If the release is significant, consider press releases to relevant news sources
  • Review the main website pages (front page and why-cayenne especially) to add any new features
  • Add a news item to the Cayenne web site
  • Send an email to the Cayenne user and developer lists
  • Send a notification email to announceATapachenews.org
  • Update http://en.wikipedia.org/wiki/Apache_Cayenne

Reference: