Making Releases

Use the number of the milestone with a “v” in front for the relase tag. For example: v4.6.2.

Create the release GitHub issue and branch

Use the GitHub issue number and the release tag for the name of the branch. For example: 4734-update-v-4.8.6-to-4.9

Note: the changes below must be the very last commits merged into the develop branch before it is merged into master and tagged for the release!

Make the following changes in the release branch:

1. Bump Version Numbers

Increment the version number to the milestone (e.g. 4.6.2) in the following two files:

  • pom.xml
  • doc/sphinx-guides/source/ (two places)

Add the version being released to the lists in the following two files:

  • doc/sphinx-guides/source/versions.rst
  • scripts/database/releases.txt

Here’s an example commit where three of the four files above were updated at once:

2. Save the EJB Database Create Script

Save the script domains/domain1/generated/ejb/dataverse/dataverse_VDCNet-ejbPU_createDDL.jdbc created by EJB during the deployment of the release candidate. Important: add semicolons to the ends of the SQL commands in the EJB-generated file (see below)! Save the resulting file as scripts/database/create/create_v{VERSION_TAG}.sql using the version number tag for the release. For example:

sed 's/$/;/' dataverse_VDCNet-ejbPU_createDDL.jdbc > scripts/database/create/create_v4.10.sql

(We are saving the script above to support the new experimental process for updating the database across multiple versions; see scripts/database/README_upgrade_across_versions.txt for more information.)

3. Check in the Changes Above...

... into the release branch, make a pull request and merge the release branch into develop.

Merge “develop” into “master”

The “develop” branch should be merged into “master” before tagging. See also the branching strategy described in the Version Control section.

Write Release Notes

Create a draft release at

Please note that the current process involves copying and pasting a running Google doc into release notes but we are conducting an experiment whereby developers can express the need for an addition to release notes by creating a file in /doc/release-notes containing the name of the issue they’re working on. Perhaps the name of the branch could be used for the filename with ”.md” appended (release notes are written in Markdown) such as To avoid accumulating many stale files over time, when a release is cut these files should probably be removed with git rm. This experiment may help inform a future experiment having to do with improvements to our process for writing SQL upgrade scripts. See the SQL Upgrade Scripts section for more on this topic.

Make Artifacts Available for Download

Upload the following artifacts to the draft release you created:

  • war file (mvn package from Jenkins)
  • installer (cd scripts/installer && make)
  • database migration script (see also the SQL Upgrade Scripts section)
  • other files as needed, such as an updated Solr schema

Publish Release

Click the “Publish release” button.

Previous: Docker, Kubernetes, and OpenShift | Next: Tools