This document is intended to be used and kept up to date by the VIVO Release Manager. It details the steps necessary to perform an official release of VIVO.
Work In-Progress (2018-05-11)
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 vivo-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.vivoweb groupId by adding a comment to the VIVO Sonatype Hosting Ticket
- You have project configuration privileges on JIRA (you'll see an error here if you don't)
Your maven settings (
~/.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>
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.
Create release branches and begin final test phase
Create a release candidate branch, release testing wiki page and notify developers to test.
RC_VERSION=1.10.0
Using the above variable, complete the below git
commands for each module being released. The modules to be released are shown in the VIVO modules release plan. A new tab 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 <develop -or- maintenance-branch> git pull git push origin <develop -or- maintenance-branch>:$rel-{RC_VERSION}-RC
Tag the release candidate branch
git checkout ${RC_VERSION}-RC git tag -a "rel-${RC_VERSION}-RC-1" -m "rel-${RC_VERSION}-RC-1" git push origin --tags
Optional - Deploy Snapshot Artifacts
If the release candidate is coming off of a "maintenance" branch instead of "develop", 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/vivoweb/vitro-webapp/
If the snapshot artifacts do not exist, you can deploy them to Sonatype with the following command:
mvn deploy -DskipTests
Build resources
Once a release has been created, it should be uploaded to GitHub as a Pre-Release. A Pre-Release should be created for jenatools, Vitro, and VIVO. The name should be "Release Candidate 1 - RC_VERSION".
Release Day
Create a new tab in the VIVO modules release plan spreadsheet.