This document is intended to be used and kept up to date by the Fedora Release MangerManager.  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).
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, 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. Wiki Markup
      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:

...

• 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

...

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

...

• 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/^{Image Removed} must be verified. todo: process for doing this

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. cp -r resources/doc/license target/site

...

1. find . -type d -name ".svn" -exec rm -rf {} \;

...

1. cd target/site
2. jar -cMf static.jar javadocs license

...

1. sftp fcrelman@fedora-commons.org
2. cd documentation
3. mkdir 3.3
4. cd 3.3
5. put static.jar
6. exit

...

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)

...

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

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:

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

...

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

...

:

• 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

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

...