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.
To make sure release day goes smoothly, you should ensure that:
~/.m2/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> |
Encrypted passwords work 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. |
The test plan should also be ready prior to code freeze.
It should include:
Create a release candidate branch, release testing wiki page and notify developers to test.
RC_VERSION=4.5.1 |
Using the above variables, complete the below git
commands for each module being released. The modules to be released are shown in the Fedora modules release plan. A new page may need to be added for this release. When the steps below are complete for a specific module, change the color to green, so that others know what's been done.
NOTE: The value of RC_VERSION
will vary for each release.
git checkout <master -or- maintenance-branch> git pull git push origin <master -or- maintenance-branch>:${RC_VERSION}-RC |
Release candidate branches CANNOT have the same version property as the master branch in the pom.xml file. The versions on the master branch will need to be incremented at the same time you create the release branches. You will need to pull in another community member to create a pull request with the version change, or another committer if you are going to create the pull requests yourself.
In this case, you can use the "versions-maven-plugin" to update project version numbers. See versions-maven-plugin documentation. For example:
mvn versions:set -DnewVersion=${RC_VERSION}-SNAPSHOT |
Verify that the previous SNAPSHOT version is no longer anywhere in the code base. Verify that the code base builds. Commit the changes.
Tag the release candidate branch
git checkout ${RC_VERSION}-RC git tag -a "<artifact-id>-${RC_VERSION}-RC-1" -m "<artifact-id>-${RC_VERSION}-RC-1" git push origin --tags |
Then we must merge the pull requests to increment the version numbers to the master branch.
Example: During the 4.5.1 release our branches should have the version 4.5.1-SNAPSHOT
, this will be incremented on the master branch to 4.5.2-SNAPSHOT
If the release candidate is coming off of a "maintenance" branch instead of master, it is possible that snapshot artifacts have not been deployed to the Sonatype snapshot repository. If this is the case, Travis will fail to build.
You can check if the snapshot artifacts exist by looking for each module. For example:
https://oss.sonatype.org/content/repositories/snapshots/org/fcrepo/fcrepo-http-commons/ |
If the snapshot artifacts do not exist, you can deploy them to Sonatype with the following command:
mvn -DaltDeploymentRepository=sonatype-nexus-snapshots::default::https://oss.sonatype.org/content/repositories/snapshots/ deploy -DskipTests |
These build scripts may be of use for building the set of release candidate modules.
Once a release has been created, it should be uploaded to GitHub as a Pre-Release. A Pre-Release should be created for fcrepo4, fcrepo-webapp-plus, and fcrepo4-vagrant. The name should be "Release Candidate 1 - RC_VERSION"
The vagrant release cannot be tested until after the fcrepo-webapps-plus RC files have been uploaded to GitHub, as the vagrant file relies on them being there first.
If any online resources have been modified or added to during the release, these must be updated.
Create a new tab in the Fedora modules release plan spreadsheet.
Notes:
These variables will be used in the examples that follow. The exact values of $ORG
and $REPO
will vary depending on which module is being released.
ORG=fcrepo4 REPO=fcrepo-module-auth-webac CURR=4.5.1 NEXT=4.5.2-SNAPSHOT |
Perform a clean checkout of the code from Github and prepare the release.
git clone git@github.com:$ORG/$REPO.git cd $REPO git checkout -b ${CURR}-RC origin/${CURR}-RC # or the release branch if named differently 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.
Resolve dependencies and set main versions to $CURR
and dev versions to $NEXT
mvn release:prepare -DreleaseVersion=$CURR -DdevelopmentVersion=$NEXT -DautoVersionSubmodules=true -DpushChanges=false |
Your GPG passphrase may not be masked in terminal.
|
Inspect/Verify local updates:
git diff HEAD~1 git diff HEAD~2 HEAD~1 |
These diffs should only contain changes of version numbers (from ${CURR}-SNAPSHOT to $CURR or $CURR to $NEXT) or occasionally HEAD to the current tag name ($REPO-$CURR)
Remove your local copies of Fedora artifacts to be sure of a clean build, and build the release.
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. |
Push the changes to Github.
git push origin --tags # mvn task relies on the tag, make sure it does not collide with a branch name |
Go to
https://github.com/fcrepo4/$REPO/releases/tag/$REPO-$CURR
ar
to jar
.For fcrepo-jetty-console on fcrepo4, you need to build and attach the JAR file to the release. This can be built with the following command: mvn clean install -Pone-click -pl fcrepo-webapp |
For fcrepo-webapp-plus you need to build and attach 4 WAR files to the release. These should be build with the commands:
After each build, upload the war file from the |
Release the build artifacts to the Sonatype repository.
mvn release:perform -DperformRelease -Dgoals=deploy |
As before, your GPG passphrase may not be masked in terminal.
|
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. |
Click Staging Repositories in left navigation
Search for "fcrepo" in upper right search box (project will not have $REPO in title)
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.
Update the Github Pages documentation:
mvn site-deploy -DskipTests |
fcrepo4 pages will be visible at http://docs.fcrepo.org/site/$CURR/$REPO/
Other module pages will be located at: $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.
|
The release branch has changes made since code freeze. It also contains the update to the version numbers for future development.
git checkout ${CURR}-RC # this is your local copy of the release branch git log |
Ensure that your commit history matches the release branch's commit history, except for the two additional commits.
fcrepo-vagrant is an exception to the above rule. The master branch of fcrepo4-exts/fcrepo-vagrant is tied to the last full release version. So you don't update the Fedora version to the new SNAPSHOT version but instead leave it at the just released (${CURR}) version. |
If this appears correct, you can push your release branch on to the maintenance branch.
git push origin ${CURR}-RC:${CURR}-maintenance |
Because there are no changes to master after code freeze and all bug fixes are on the ${CURR}-RC branch, this will operate as a fast-forward merge. |
Current, in-progress Fedora Repository Documentation wiki: https://wiki.duraspace.org/display/FEDORA4x
At the very minimum, update the following:
Documentation
Downloads
Release Notes
Fedora Upgrade 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.
Fedora Repository site (Drupal): http://www.fedorarepository.org/
Let Carol Minton Morris know that the release is complete and can be announced.
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.1 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 |