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

Compare with Current View Page History

« Previous Version 41 Next »

Table of Contents

This document is intended to be used and kept up to date by the Fedora Release Manger.  It details the 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, release, and shell access 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 the following sections:
    1.  _inclusionsLibrary (at the top)
    2. TreeNavigation (at the bottom)
  5. Click Export and save it as fedora-3.2.1-docs.zip
  6. Upload the zip file to fedora-commons.org
    1. sftp fcrelman@fedora-commons.org
    2. cd documentation/3.2.1 (this directory should already exist)
    3. put fedora-3.2.1-docs.zip
    4. exit
  7. Unpack the zip file in the appropriate directory
    1. ssh fcrelman@fedora-commons.org
    2. cd documentation/3.2.1
    3. unzip fedora-3.2.1.zip
    4. mv FCR30/* .
    5. rmdir FCR30
    6. 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. mv index.html to index-inside.html
    3. cp ../3.2/index.html .
  9. Edit the index-inside.html page, cleaning it up and providing a link to download the documentation for offline viewing.
    1. Open the file (e.g., in vi) and search for the text "Space Details:", replacing it with "Fedora 3.2.1 Documentation"

    2. Insert a new line below that one, with the following HTML:
      [ <a href="fedora-3.2.1-docs.zip">Download zip for offline viewing</a> ]

    3. A couple lines below, you will see the start of a table tag.  Remove that line, and every line below, up to and including the closing table tag.
    4. A few lines below that, change the text "Available Pages:" with "Index:"

Prepare and distribute documentation plan

The documentation plan should be ready prior to code freeze.

It should include which sections of the documentation need to be updated, and by whom.  Besides new/modified feature documentation, the following need to be updated for each release:

  • Release notes.  These should start with a 1 or 2-paragraph summary of the release, which should be sent to Carol Minton Morris (clt6 at cornell dot edu) for review several days prior to release day.  This text will be incorporated in the release announcement.
  • Upgrade/Migration guide
  • Installation/Configuration guide
  • Front page of documentation wiki (to be modified in place on release day...see "Complete wiki documentation updates" section below for details)

Prepare and distribute test plan

The test plan should also 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 compatibility tests (GSearch, OAIProvider, SWORD-Fedora, DirIngest) 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.  The code will be frozen after the last committer meeting prior to the start of the test phase in order to give committers the opportunity to object to the imminent code freeze due to important outstanding changes.
Once the group consensus is reached, announce the code freeze 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

Prepare static documentation area on website

For each Fedora release, there is a permanent documentation URL on the fedora-commons.org website.

For example, http://fedora-commons.org/documentation/3.2

This URL will always resolve to the appropriate copy of the documentation for that version of Fedora.  For old releases, it will contain a browsable archive of the documentation for that release.  For the current release, it will automatically forward to the live documentation wiki: http://fedora-commons.org/go/fcr30

In addition, this area is the place to serve static documentation that doesn't naturally fit in the wiki, such as generated documentation (javadocs) and third-party license information for the release.

To prepare this area for the new release:

  1. Build the aggregate javadocs for all of trunk
    1. mvn javadoc:javadoc (this will build them in target/site/apidocs)
    2. mv target/site/apidocs target/site/javadocs
  2. Copy the license information to target/site
    1. cp -r resources/doc/license target/site
  3. Recursively delete all .svn directories in target/site/license
    1. find . -type d -name ".svn" -exec rm -rf {} \;
  4. Create a jar file to upload
    1. cd target/site
    2. jar -cMf static.jar javadocs license
  5. Upload the jar to fedora-commons.org
    1. sftp fcrelman@fedora-commons.org
    2. cd documentation
    3. mkdir 3.3
    4. cd 3.3
    5. put static.jar
    6. exit
  6. Unpack the jar and ensure the static documentation is viewable on the web
    1. ssh fcrelman@fedora-commons.org
    2. cd documentation/3.3
    3. jar -xf static.jar
    4. rm static.jar
    5. Point your browser to http://fedora-commons.org/documentation/3.3/javadocs and http://fedora-commons.org/documentation/3.3/license/license.html (these are the full URLs that should be referenced from the documentation in the wiki)
  7. Ensure the main documentation URL for this version forwards to the wiki
    1. cp ../index.html . (the parent directory already contains an index.html that forwards to the right place in the wiki)
    2. Point your browser to http://fedora-commons.org/documentation/3.3 (it should redirect to the FCR30 wiki space)

Update the KEYS file

Make sure the KEYS file in subversion is up-to-date with the latest, exported public keys of the committers (and most importantly, the release manager).  For more information on this file, see this page.

For *nix systems use the following command to add a missing key to the KEYS file:
(gpg --list-sigs AB76196 && gpg -a --export AB76196) >> KEYS

Tag the release

Tag the trunk based on the version of the release (e.g. svn copy to tags/release-3.3)

Build the final distribution

In order to build the release make sure that:

  • you have a working PGP installation with your code signing key as the default key
  • the version number has been increased and tagged in SVN

Invoke Maven with the following command to generate the release (future releases should be done using the Maven release plugin once the remaining Maven issues are resolved):
mvn clean install -Pfedora-release
Grab the artifacts outlined below along with their md5 sums and pgp signatures.

The distribution should consist of:

Filename

Description

fcrepo-src-N.M.zip

A complete source distribution zip file

fcrepo-installer-N.M.jar

The fedora-repository installer jar

fcrepo-client-messaging-N.M.zip

The fedora-messaging-client distribution

fcrepo-server-rmi-journal-rcv-N.M.zip

The fedora-journaling-rmi-reciever distribution

Each file must have an associated md5 checksum and the pgp key signature of the release manager.

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). Also check the PGP signature.

Change the primary download page on sourceforge so it points to the new fcrepo 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 all files we release to sourceforge.

To do this:

  1. sftp fcrelman@fedora-commons.org
  2. cd 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

At this point, the completed documentation should be ready to be "swapped in" and made live in the wiki.

  • Rename the SPACE using the new version number, e.g. "Fedora Repository 3.3 Documentation".  This will ensure that the version number is visible in the header area of all pages within the documentation.
  • Update the front page of the space:
    • Rename the PAGE the same as the SPACE, e.g. "Fedora Repository 3.3 Documentation".  This will ensure that the version number is obvious and prominent in the content area of the main documentation page.  It will also cause anyone with bookmarks to the old main page to realize that the version of the current documentation has been updated.  After clicking the suggested link on the 404 page, they will see where they can access the archived documentation.
    • Update the content of the page:
      • All download links should point to the new version's files
      • The javadoc link should go the javadocs URL for the new version
      • Linkage for "Older Versions" of documentation should be updated to include a link to the documentation snapshot for the now-previous version.
  • Update the Release Notes parent page.
  • Update the License and copyright page.
  • Make any final changes to the new release notes page
  • Remove all warnings about a feature being for (this) future release of Fedora
  • Update the "Upgrade and Migration Guide" with the new content.
  • Update the "Installation and Configuration Guide" with the new content.
  • Make sure the copyright at the bottom of all doc pages is accurate.

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

Let Carol Minton Morris (clt6 at cornell dot edu) know that the release is complete and can be announced.

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

  • The DuraSpace blog
  • The fedora-commons.org homepage (as a news item)
  • Twitter (@FedoraRepo, others)
  • Mailing lists (fedora users, developers, possibly others)
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels