Page tree
Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 70 Next »

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.

 

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 edit privileges on the duraspace.org Confluence wiki.
  • You have an oss.sonatype.org 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
  • You have project configuration privileges on JIRA (you'll see an error here if you don't)
  • 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>

Note about encrypted passwords

Encrypted passwords works for the plugin that references the sonatype-nexus passwords, but NOT the one that uses github.  To avoid a cryptic error, enter your github password in plaintext.

Ensure you have a trusted code signing key

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 release-4.0.0
git push origin release-4.0.0

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.

Create a new tab in the Fedora modules release plan spreadsheet.

Notes: 

  1. Follow the release order of the spreadsheet plan
  2. Some projects need pom.xml dependency version properties to be updated prior to release (e.g. fcrepo-camel-toolbox). This should be documented starting with 4.4.1.

Variables Used

ORG=fcrepo4
REPO=fcrepo-module-auth-webac
CURR=4.5.0
NEXT=4.5.1-SNAPSHOT

Github Release

git clone git@github.com:$ORG/$REPO.git
cd $REPO
git checkout rc-$CURR
mvn release:clean

If release:clean fails, you may need to revert the RC commit with git revert HEAD.  If the parent snapshot is not available, build an old version of fcrepo4 to populate it locally.

mvn release:prepare -DreleaseVersion=$CURR -DdevelopmentVersion=$NEXT -DautoVersionSubmodules=true -DpushChanges=false

Resolve dependencies and set main versions to $CURR and dev versions to $NEXT

Your GPG passphrase will not be masked in terminal.

rm -rf ~/.m2/repository/org/fcrepo
git checkout $REPO-$CURR # detached head state
mvn clean install

Up until this point, all of the changes made are strictly in your local repository and working directory.  From this point on, the changes you make will be visible to the world and in some cases difficult to back-out of. 

git push origin rc-$CURR:release-$CURR
git push origin --tags

 

  • Go to https://github.com/fcrepo4/$REPO/releases/tag/$REPO-$CURR

  • Click Edit tag, and update title to "Release $CURR"
  • If appropriate, attach binaries and checksums at the bottom
  • Click Publish Release

Sonatype Release

mvn release:perform -DperformRelease -Dgoals=deploy

As before, your GPG passphrase will not be masked in terminal.

Point of no return

The following steps, once completed are final.  They cannot be undone, revoked or altered.  Only proceed if you've completed all the above steps and are absolutely certain the release is ready for publication.

  • Go to https://oss.sonatype.org/index.html#nexus-search;gav~org.fcrepo~$REPO and log in
  • Click Staging Repositories in left navigation

  • Search for "fcrepo" in upper right search box (project will not have $REPO in title)

  • Select repository and verify that $REPO is present in the Content tab
  • Click Close, then Refresh, then Release

This will publish the artifacts to the Sonatype releases repository and start the process of syncing them with Maven Central, which may take several hours. When finished, they'll be available at http://repo1.maven.org/maven2/org/fcrepo.

Github Pages

mvn site-deploy -DskipTests

The pages will be visible at http://$ORG.github.io/$REPO/site/$CURR/fcrepo/$REPO/.

For fcrepo4/fcrepo4 and fcrepo4-exts/fcrepo-camel, manually add links to the current releases.  The easiest way to do this is to search for an old version number and copy/update for the current release.

Troubleshooting

 Click here to expand...

Error creating blob: API rate limit exceeded

Github only allows a certain number of requests per hour.  Once that number is hit you'll have to wait an hour before resuming your operation.  The site documentation may exhaust this limit several times.

If you get the following error:

Error creating blob: You have triggered an abuse detection mechanism and have been temporarily 
blocked from calling the API. Please retry your request again later. (403)

You may consider using the patched version of site-maven-plugin: https://github.com/awoods/maven-plugins/commit/c62c7b168375e3bfaf0dec7de2fa5fc03d8ed173

Merge With Master

git checkout master
git merge rc-$CURR
git push origin master

Ontologies

Ontologies are released on their own schedule and do not need to be released.  But they should be tagged with the current version when a release is performed, to make it easy to identify the version of the ontology that each release was using.

CURR=4.5.0
ORG=fcrepo4
REPO=fcrepo-webac-ontology
git clone git@github.com:$ORG/$REPO
cd $REPO
git tag -a "$REPO-$CURR" -m "$REPO-$CURR" # except fcrepo4/ontology should be fcrepo-ontology-$CURR
git push --tags

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.

  • Add the following header to the previous major release wiki space (see: Space Admin -> Themes -> Configure Theme)

    {note:title=Old Release}
    This documentation covers an old version of Fedora. Looking for another version? [See all documentation|FF:Documentation].
    {note}

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.

Close the release in Jira, and create the next one

  1. Go to the release management page.
  2. For the release you just made (there should be an open package icon to the left of it)
    1. click the gear icon on the left and choose "release"
    2. enter the date you finished the release
    3. the package should be closed
    4. if you are not already listed as the release manager in the description, enter "Release Manager: your-name-here"
  3. Create the next release
    1. enter a name (ie, Fedora 4.x.y) in the form at the top, and click Add.  If the release manager is known, enter that in the note.

Update the Fedora Repository site

Fedora Repository site (Drupal): http://www.fedorarepository.org/

  • No need to perform this step until the website refactor has been performed.

Announce release

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




  • No labels