This document is intended to be used and kept up to date by the Fedora Release MangerManager.  It details the technical 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).
X is the major point version, Y is the minor point version, and Z is the maintenance point.

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

...

• You have an account with commit and release privileges , 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.  _inclusionsLibrary (at the top)
2. TreeNavigation (at the bottom)

...

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

...

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/

...

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 .

...

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> \]

...

• 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.

...

• 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.  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

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^{Image Removed}

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^{Image Removed}

In addition, this area is a convenient place to hold 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. Create a jar file to upload
   1. cd target/site
   2. jar -cMf static.jar javadocs license
4. 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
5. 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^{Image Removed} and /license/license.html (these are the full URLs that should be referenced from the documentation in the wiki)
6. Ensure the documentation URL forwards to the wiki
   1. cp ../index.html .
   2. Point your browser to http://fedora-commons.org/documentation/3.3^{Image Removed} (it should redirect to the FCR30 wiki space)

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

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.

• If releasing on JDK 8, ensure that the javadoc:javadoc mvn target runs before beginning the release process (it has more stringent validations in JDK 8)- if necessary, use the Java endorsed standards override mechanism to ensure the JAXB implementation version is at least 2.2.11. This is so that the WSDL and XSD generated classes will produce valid javadoc output.

Create release branch and begin 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 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

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):

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 https://oss.sonatype.org

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 "release" folder.  In the release notes box, paste the URL to the appropriate release notes page in the documentation wiki.version numbered folder under https://sourceforge.net/projects/fedora-commons/files/fedora/

The artifacts to be uploaded to Sourceforge, as well as PGP signatures, SHA1 checksums, file sizes, etc., can be found at the central Maven repository search site: http://search.maven.org/#search%7Cga%7C1%7Corg.fcrepo.

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

For each file, also add a *.asc file, containing the PGP signature for the file, as created by Maven and stored in the central repository.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 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 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:

...

:

• In the file manager view, click on the "i" icon next to the fcrepo-installer-X.Y.jar file you just uploaded
• Select all for "Default Download For:".

It may take up to five minutes for all the Sourceforge links to be updated.

Complete the Duraspace wiki documentation updates

Current Fedora Repository Documentation wiki: https://wiki.duraspace.org/display/FEDORA38

At the very minimum, update the following:

Downloads
Release Notes

If this is a new major or minor point release, copy the previous point release documentation to create the current wiki (/FEDORAXY), then update accordingly. Mark the new pages as current, and update the pages in the previous documentation to indicate they are out-of-date.

If this is a maintenance point release, create separate child release note pages for each release covered by the documentation (see https://wiki.duraspace.org/display/FEDORA38/Release+Notes for an example).
Otherwise, post the release notes in the Release Notes page (see https://wiki.duraspace.org/display/FEDORA35/Release+Notes for an example).

Update any other documentation as needed, per changes/features added with this release.

Make sure the license and copyright

...

information is up-to-date with

...

On the homepage:

...

this release.

Announce release

Send a short summary of this release, and a link to the release notes, to Let Carol Minton Morris (clt6 at cornell dot edu) and work with her to send out the release announcementknow 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)