You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

This document is intended to be kept up to date by the Akubra Release Manager.  It details the steps necessary to perform snapshot and official releases of Akubra.

Prerequisites

Verify Release Privileges

To perform a release, you must have:

  • Write access to the Akubra subversion repository hosted at fedora-commons.org.  This requires an administrator to add you to the akubra-committer LDAP group.
  • Write access to the org.akubraproject groupId in the snapshot and staging repositories hosted at oss.sonatype.org.  If you don't already have this, you will need to:
  • The login details for the fcrelman account at fedora-commons.org.  This is only required for official releases, not snapshots.  If you don't have this information yet, you can get it from the previous release manager.

Update Maven settings.xml

Akubra's root pom.xml already has the correct staging and snapshot repositories listed in the distributionManagement section.  In order to deploy, you will need to add your Sonatype OSS username and password to your local ~/.m2/settings.xml file:

<settings>
  <servers>
    <server>
      <id>sonatype-nexus-snapshots</id>
      <username>YourUsername</username>
      <password>YourPassword</password>
    </server>
    <server>
      <id>sonatype-nexus-staging</id>
      <username>YourUsername</username>
      <password>YourPassword</password>
    </server>
  </servers>
</settings>

Avoid Maven 2.2.0

Make sure you're using a recent version of Maven. As of this writing, the latest was 2.2.1, and it worked fine. In particular, avoid version 2.2.0: it has a serious bug that affects deployments: MNG-4235.

Snapshot Releases

From a clean, up-to-date copy of trunk, run the following command:

  • mvn clean javadoc:jar source:jar deploy

The snapshot will be immediately available in the public Sonatype repository: http://oss.sonatype.org/content/groups/public

Official Releases

Update KEYS

Make sure the KEYS file at the root of the source tree has your up to date public code signing key and signatures listed. If you don't yet have a code signing key, see Creating a Code Signing Key. When you are ready, append your key with the following command:

  • (gpg --list-sigs YourKeyID && gpg -a --export YourKeyID) >> KEYS

Do a Dry Run

This step is not required, but performs a useful sanity check without committing any changes. From a clean, up-to-date copy of trunk, run the following command:

  • mvn release:prepare -DdryRun=true

Tag and Increment Version

This step will set the version declared in the project's pom.xml files, commit the changes to trunk, tag the release, and finally, check in another trunk change that increments the next development version (e.g. x.y-SNAPSHOT) in the pom.xml files.

  • mvn release:prepare -Dresume=false -Dusername=YourSVNUsername -Dpassword=YourSVNPassword

Note: This may fail to compile part way through the process, complaining that an internal project dependency is not met. If this occurs, don't worry. Just run the following:

  • mvn install
  • mvn release:prepare -Dusername=YourSVNUsername -Dpassword=YourSVNPassword

If backing out of this step is needed for any reason, the following will restore the subversion repository and your working copy to the state it was previously in:

Deploy Artifacts to Staging

This step will push all release artifacts to the staging repository.

  • Check out the tagged release from subversion and "mvn install" it.
  • Change back to trunk
  • mvn release:perform -Darguments="-Dgpg.keyname=YourKeyId -Dgpg.passphrase=YourKeyPassword"

Verify and Promote Staged Artifacts

  • Log into http://oss.sonatype.org/ UI, click Staging in the left column, then select the staged repository on the right. It will open below. Right click on it and select Close.
  • Download and test that the artifacts in staging are exactly as they should be once deployed to central.

If anything is incorrect, right click the staged repository and select "Drop". After the problem is resolved, you can re-deploy the artifacts to staging and verify them again. To re-deploy and already-tagged release:

If everything looks good, right click on the repository and select "Promote". The artifacts should be synced to central within an hour.

Upload Static Documentation

The release:perform step should have created a static maven site for the release (including javadocs) in /tmp/akubra-site. This step will make that documentation available at the appropriate place on the fedora-commons.org website.

  1. cd /tmp
  2. mv akubra-site site
  3. jar -cMf site.jar site
  4. sftp fcrelman@fedora-commons.org
  5. cd documentation/akubra
  6. mkdir x.y
  7. cd x.y
  8. put site.jar
  9. exit
  10. ssh fcrelman@fedora-commons.org
  11. cd documentation/akubra/x.y
  12. jar -xvf site.jar
  13. rm site.jar
  14. exit

Verify the documentation is available at http://fedora-commons.org/documentation/akubra/x.y/site/

Archive the Release

  1. Make a local copy of all the artifacts, checksums, and signatures published to central for this release, putting them in a local directory called akubra-x.y. (If you find a scriptable way to do this, please add it here...)
  2. jar -cMf akubra-x.y.jar akubra-x.y
  3. sftp fcrelman@fedora-commons.org
  4. cd /home/fedcommbkup/release-archive
  5. cd YYYY (e.g. 2010, if it doesn't exist, create it)
  6. mkdir MM-DD (e.g. 03-13, the release date)
  7. cd MM-DD
  8. put akubra-x.y.jar
  9. exit
  10. ssh fcrelman@fedora-commons.org
  11. cd /home/fedcommbkup/release-archive/YYYY/MM-DD
  12. jar -xvf akubra-x.y.jar
  13. rm akubra-x.y.jar
  14. exit

Update the Wiki

Add release notes an update all links on this page.

  • No labels