This document is intended to be used and kept up to date by the Release Manger.  It details the technical steps necessary to perform an official release of Fedora.

Before Release Day

Verify release privileges

To make sure release day goes smoothly, you should ensure that:

• You have an account with commit and release privileges for the fedora-commons project on sourceforge.net. As a committer, you should already have this level of access.
• You have the login details for the fcrelman account at fedora-commons.org.  If you don't have this information yet, you can get it from the previous release manager.

Snapshot previous documentation

This step should be done before major changes are made to the documentation wiki for the new release.

1. Go to the documentation space's homepage: http://fedora-commons.org/go/fcr30
2. Select Browse -> Advanced
3. Select HTML Export
4. De-select _inclusionsLibrary and everything beneath it
5. Click Export
6. Upload the zip file to fedora-commons.org
   1. sftp fcrelman@fedora-commons.org
   2. put filename.zip
   3. exit
7. Unpack the zip file in the appropriate directory
   1. ssh fcrelman@fedora-commons.org
   2. mkdir ~/documentation/3.2.1/ (if it doesn't exist yet)
   3. cd ~/documentation/3.2.1
   4. unzip filename.zip
   5. Make sure it's viewable at http://fedora-commons.org/documentation/3.2.1/
8. Put the documentation in a warning frame.  This serves to remind people viewing old documentation that there is a newer version of Fedora available.
   1. See http://fedora-commons.org/documentation/3.2/ as an example of what it will look like.
   2. Move index.html to index-inside.html
   3. Copy ../3.2/index.html to index.html
9. Edit the table of contents. 

Prepare and distribute test plan

The test plan should be ready prior to code freeze.

It should include:

• Which platform/database combinations will be tested
• Which automated tests will be run, and by whom
• Which manual tests will be run, and by whom
• Which service tests will be run, and by whom
• Instructions on how testers will report on test results

Announce code freeze + test phase

Approximately a week before release, the trunk should be frozen for code updates.  Announce this to the dev mailing list.

At this stage, the only updates that may occur in trunk are non-code related or any problem discovered during testing that is considered a show-stopper.  As release manager, you will need to make judgements on a case-by-case basis on what kind of problem constitutes a show-stopper for the release, and whether the release date should be pushed to allow for additional testing.

Release Day

Copy license and javadocs to static area on website

TODO: Describe this

Tag the release

Tag the trunk based on the version of the release (svn copy to tags/release-VERSION)

Build the final distribution

TODO: We need a maven target, or targets for this.

The distribution should consist of:

• A complete source distribution zip file
• The fedora-repository installer jar
• The fedora-messaging-client distribution
• The fedora-journaling-rmi-reciever distribution
• An associated .md5 chucksum file for each of the above files

Each filename should include the version number of the Fedora release.

Upload and verify the distribution

Upload all files to the fedora-commons project at sourceforge.net.  Follow the pattern established for previous releases, where all files associated with the release reside in a single "release" folder.  In the release notes box, paste the URL to the appropriate release notes page in the documentation wiki.

After uploading, download each file and verify the md5 checksums locally (e.g., using md5sum).

Change the primary download page on sourceforge so it points to the new fedora-repository installer jar, and change the additional downloads to include the other (non-md5) files.

Archive the distribution

For disaster recovery purposes, we keep an archive of files we release to sourceforge.

To do this:

1. sftp to fedora-commons.org using the fcrelman account
2. Follow the symlink at ~/release-archive
3. Create a subdirectory based on the release date, e.g. 2009/12-07/fedora-3.3/
4. Upload all released files to this directory.

Complete wiki documentation updates

...

Update high-level pages on fedora-commons.org website

In the Software section:

• Make sure the default view for the Fedora Repository reflects the new release
• Update the previous version to point to the archived documentation
• Make sure the license information is up-to-date with the latest release

On the homepage:

• Make sure the link to the current version goes to the right place and is labeled properly.

Announce release

Send a short summary of this release, and a link to the release notes, to Carol Minton Morris (clt6 at cornell dot edu) and work with her to send out the release announcement.

Depending on the significance of the release, the announcement will be disseminated in various forms to:

• The DuraSpace blog
• The fedora-commons.org homepage (a news item)
• Twitter (@FedoraRepo, others)
• Mailing lists (fedora users, developers, possibly others)