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