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 4.0.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 4.0).

Before Release Day

Verify release privileges

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

• You have an account with commit access for the fedora project on github. As a committer, you should already have this level of access.
• You have an account with manager privileges on the Fedora Repository Drupal site.
• 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>
    <server>
      <id>github</id>
      <username>your-github-id</username>
      <password>your-github-pwd</password>
    </server>
  </servers>
  ...
</settings>

Ensure you have a trusted code signing key

• create one if you haven't before
• ensure that it's listed within the contributor keys

Prepare and distribute test plan

The test plan should also be ready prior to code freeze.

It should include:

• Which platform/configuration 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 (external search, external triplestore) will be run, and by whom
• Instructions on how testers will report on test results

Create release branch and begin final test phase

Create a release candidate branch, release testing wiki page and notify developers to test.

git checkout -b fcrepo-4.0.0-beta-01-RC
git push origin fcrepo-4.0.0-beta-01-RC

Update online resources

If any online resources have been modified or added to during the release, these must be updated.

Release Day

Determine which modules will be released.

Of the projects in https://github.com/fcrepo4. which should be released.  Typically we keep the release versions in sync for those that have had a formal release.

Release Order

Due to dependency chains, the following release order is required.  Furthermore, the artifacts of dependencies must be propagated to maven central before the next one can be released.

1. fcrepo-build-tools: if schedule for a release, must be handled first since it's version number is present in the other modules
2. fcrepo4: the main project, always part of a release, takes the vast majority of the time (also push gh-pages)
3. fcrepo-message-consumer (also push gh-pages)
4. fcrepo-module-auth-rbacl (also push gh-pages)
5. fcrepo-module-auth-xacml (also push gh-pages)
6. fcrepo4-client (also push gh-pages)
7. fcrepo-camel (also push gh-pages)
8. ----
9. fcrepo-sample-dataset (no push to sonatype, just version bump)
10. fcrepo-webapp-plus (ditto re:no push to sonatype)
11. fcrepo4-release-tests (ditto)
12. fcrepo4-oaiprovider (ditto)
13. ontology (ditto)

Merge the release candidate branch into master (if any commits were made)

git checkout fcrepo-4.0.0-beta-01-RC
git pull origin fcrepo-4.0.0-beta-01-RC
git checkout master
git merge fcrepo-4.0.0-beta-01-RC
git push origin master
git branch -d fcrepo-4.0.0-beta-01-RC
git push origin :fcrepo-4.0.0-beta-01-RC

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:

git checkout -b local-release
mvn release:clean
mvn release:prepare -DreleaseVersion=X.X.X -DdevelopmentVersion=X.X.Y-SNAPSHOT -DautoVersionSubmodules=true -DpushChanges=false
Note: If there are javadoc failures, use the following, then file a JIRA ticket for the next development cycle
mvn release:prepare -DreleaseVersion=X.X.X -DdevelopmentVersion=X.X.Y-SNAPSHOT -DautoVersionSubmodules=true -DpushChanges=false -Darguments="-Dmaven.javadoc.failOnError=false"

• Review the local commits for correctness (`git diff HEAD~1`, and `git diff HEAD~2`)

• Remove/or move local Maven repository

mv ~/.m2/repository ~/.m2/repository-yyyy-mm-dd

• Checkout tag
• Build/Test release tag

git checkout <release-tag>
mvn clean install

• Push tags and commits to GitHub

git push origin local-release:master
git push origin --tags

• return to the release tag

git checkout <release-tag>

• Deploy to Sonatype

mvn release:perform -DperformRelease -Dgoals=deploy

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.

Build GitHub documentation site

Checkout release tag for publishing the release documentation

mvn site-deploy -DskipTests
** Resume from a given module, if necessary
mvn site-deploy -DskipTests -rf <module>

Update index.html pages in branch "gh-pages" for releases projects: fcrepo4, fcrepo-message-consumer, fcrepo-module-auth-xacml, etc

Troubleshooting site-deploy

Create GitHub release

Under GitHub account/releases, select "Draft new release".

• Write a description

• Create MD5 and SHA1 files for each of the release artifacts

  compute-checksums.sh

  for x in `ls *.war`; do echo $x; md5sum $x > ${x}.md5; sha1sum $x > ${x}.sha1; done

• Upload artifacts to GitHub release (war, war.md5, war.sha1)

Complete the Duraspace wiki documentation updates

Current, in-progress Fedora Repository Documentation wiki: https://wiki.duraspace.org/display/FEDORA4x

At the very minimum, update the following:

Downloads
Release Notes

Note the version of Java against which the release was built.

If this is a new major or minor point release, copy the current, in-progress documentation to create the release wiki, 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.
Otherwise, post the release notes in the Release Notes page (see Fedora 4.0.0 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 this release.

Update the Fedora Repository site

Fedora Repository site (Drupal): http://www.fedorarepository.org/
Sitemap: http://www.fedora-commons.org/sitemap

1. Edit Software -> Current Release to refer to the new version of the software
2. Edit Software -> Copyright to update the copyright date, if necessary
3. Edit Get Started -> Getting Started to refer to the new version of the software

Announce release

Let Carol Minton Morris know that the release is complete and can be announced.