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

Compare with Current View Page History

« Previous Version 56 Next »

Table of Contents

This Document is Out of Date

We expect the release process to change as part of the 3.6 release, at which time the steps outlined here will be updated accordingly.

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

The release version in the documentation below is identified as X.Y, replace this in the instructions with the current release (eg 3.6.1).

The previous release version (snapshot previous documentation) is identified as A.B, replace this with the previous release (eg 3.6).

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 an account with manager privileges on the Fedora Commons Plone wiki.
  • You have an account with edit privileges on the duraspace.org Confluence wiki.
  • You have an oss.sonatype.com account and have requested to be given permission to publish to the org.fcrepo groupId by adding a comment to the Fedora Sonatype Hosting Ticket
  • Your maven settings.xml includes the following:
<settings>
  ...
  <servers>
    ...
    <server>
      <id>sonatype-nexus-snapshots</id>
      <username>your-jira-id</username>
      <password>your-jira-pwd</password>
    </server>
    <server>
      <id>sonatype-nexus-staging</id>
      <username>your-jira-id</username>
      <password>your-jira-pwd</password>
    </server>
  </servers>
  ...
</settings>

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

Create release branch and being final test phase

Update online resources

If any online resources have been modified or added to during the release, these must be updated. Particularly XSD schema files served at http://www.fedora-commons.org/definitions/1/0/ must be verified.

Release Day

Update documentation area on the Fedora Commons wiki

Fedora Commons Wiki (Plone): http://www.fedora-commons.org/
Sitemap: http://www.fedora-commons.org/sitemap

  1. Copy Software -> Current Release to Software -> Previous Releases -> Release X.Y
    Move Release X.Y to the top of the list of release pages.
    Change state to published in green view tab, state: in green right-hand drop-down menu
    Select Release X.Y as the default page to display for the Previous Releases folder:
    • navigate to Previous Releases folder
    • select green view tab
    • select display drop-down menu
    • select change content item as default view...
  2. Edit Software -> Current Release to refer to the new version of the software
  3. Edit the Software page to update the Download link: http://downloads.sourceforge.net/fedora-commons/fcrepo-installer-X.Y.Z.jar
  4. Edit the Home page:
  5. Edit the Announcements folder:
    • add a Fedora Repository X.Y.Z Released page
    • move the page to top of Announcements list
    • On the day of the announcement:
      • change state the state of the page to published
      • expire previous release announcement page

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

Build and release the final distribution to Maven Central

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 git

Run the following commands to generate and upload all built artifacts to the Sonatype staging repository
(the "DreleaseVersion and -DdevelopmentVersion" arguments are optional-you'll just be prompted for them otherwise):

git checkout v{{*X.Y}}
mvn release:prepare -DdryRun -DreleaseVersion=X.X.X -DdevelopmentVersion=X.X.Y-SNAPSHOT
mvn release:clean && mvn release:prepare -DreleaseVersion=X.X.X -DdevelopmentVersion=X.X.Y-SNAPSHOT
mvn release:perform

Login to oss.sonatype.com

Find the staging repository, check that it looks good, and "Close" it. Then "Release" it. This will publish the artifacts to the Sonatype releases repository and start the process of syncing them with central. The artifacts may take several hours to reach central. When finished, they'll be available at http://repo1.maven.org/maven2/org/fcrepo.

Upload selected artifacts to Sourceforge and verify the distribution

Upload all files listed below 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 version numbered folder.

Files sent to sourceforge and linked directly from the documentation's Download page should include:

Filename

Description

fcrepo-src-X.Y.zip

A complete source distribution zip file

fcrepo-installer-X.Y.jar

The fedora-repository installer jar

fcrepo-client-messaging-X.Y.zip

The fedora-messaging-client distribution

fcrepo-server-rmi-journal-rcv-X.Y.zip

The fedora-journaling-rmi-reciever distribution

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.

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

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