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.

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

Some of the previous steps can be done directly into github interface as described in following tutorials:

https://help.github.com/articles/creating-and-deleting-branches-within-your-repository/

https://help.github.com/articles/creating-releases/

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.