Versions Compared

Old Version 6

changes.mady.by.user Chris Wilper

Saved on

compared with

New Version 7

changes.mady.by.user Chris Wilper

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

...

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

...

  • 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

...

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.

...

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/

...

  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 and update all links on this page.