See Version Control for background on our branching strategy.
The steps below describe making both regular releases and hotfix releases.
Developers 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. The name of the branch could be used for the filename with “.md” appended (release notes are written in Markdown) such as
The task at or near release time is to collect these notes into a single doc.
Create an issue in GitHub to track the work of creating release notes for the upcoming release.
Create a branch, add a .md file for the release (ex. 5.10.1 Release Notes) in
/doc/release-notesand write the release notes, making sure to pull content from the issue-specific release notes mentioned above.
Delete the previously-created, issue-specific release notes as the content is added to the main release notes file.
Take the release notes .md through the regular Code Review and QA process.
Usually we branch from the “develop” branch to create the release branch. If we are creating a hotfix for a particular version (5.11, for example), we branch from the tag (e.g.
Use the GitHub issue number and the release tag for the name of the branch. (e.g.
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.
Increment the version number to the milestone (e.g. 5.10.1) in the following two files:
<revision>(e.g. pom.xml commit)
doc/sphinx-guides/source/conf.py (two places, e.g. conf.py commit)
Add the version being released to the lists in the following file:
doc/sphinx-guides/source/versions.rst (e.g. versions.rst commit)
For a regular release, make the changes above in the release branch you created, make a pull request, and merge it into the “develop” branch. Like usual, you can safely delete the branch after the merge is complete.
If you are making a hotfix release, make the pull request against the “master” branch. Do not delete the branch after merging because we will later merge it into the “develop” branch to pick up the hotfix. More on this later.
Either way, as usual, you should ensure that all tests are passing. Please note that you will need to bump the version in jenkins.yml in dataverse-ansible to get the tests to pass. Consider doing this before making the pull request. Alternatively, you can bump jenkins.yml after making the pull request and re-run the Jenkins job to make sure tests pass.
If this is a regular (non-hotfix) release, create a pull request to merge the “develop” branch into the “master” branch using this “compare” link: https://github.com/IQSS/dataverse/compare/master…develop
Once important tests have passed (compile, unit tests, etc.), merge the pull request. Don’t worry about style tests failing such as for shell scripts.
If this is a hotfix release, skip this whole “merge develop to master” step (the “develop” branch is not involved until later).
Go to https://jenkins.dataverse.org/job/guides.dataverse.org/ and make the following adjustments to the config:
Branch Specifier (blank for ‘any’):
VERSION(under “Build Steps”):
Click “Save” then “Build Now”.
Make sure the guides directory appears in the expected location such as https://guides.dataverse.org/en/5.10.1/
As described below, we’ll soon point the “latest” symlink to that new directory.
Go to https://github.com/IQSS/dataverse/releases/new to start creating a draft release.
Under “Choose a tag” you will be creating a new tag. Have it start with a “v” such as
v5.10.1. Click “Create new tag on publish”.
Under “Target” go to “Recent Commits” and select the merge commit from when you merged
masterabove. This commit will appear in
/api/info/versionfrom a running installation.
Under “Release title” use the same name as the tag such as
In the description, copy and paste the content from the release notes .md file created in the “Write Release Notes” steps above.
Click “Save draft” because we do not want to publish the release yet.
At this point you can send around the draft release for any final feedback. Links to the guides for this release should be working now, since you build them above.
Make corrections to the draft, if necessary. It will be out of sync with the .md file, but that’s ok (#7988 is tracking this).
ssh into the dataverse-internal server and undeploy the current war file.
Go to https://jenkins.dataverse.org/job/IQSS_Dataverse_Internal/ and make the following adjustments to the config:
Branch Specifier (blank for ‘any’):
Execute shell: Update version in filenames to
Click “Save” then “Build Now”.
The build number will appear in
/api/info/version (along with the commit mentioned above) from a running installation (e.g.
ssh into the dataverse-internal server and do the following:
In a git checkout of the dataverse source switch to the master branch and pull the latest.
Copy the war file from the previous step to the
targetdirectory in the root of the repo (create it, if necessary).
A zip file called
dvinstall.zip should be produced.
Upload the following artifacts to the draft release you created:
the war file (e.g.
dataverse-5.10.1.war, from above)
the installer (
dvinstall.zip, from above)
other files as needed:
updated Solr schema
metadata block tsv files
Click the “Publish release” button.
You can find our milestones at https://github.com/IQSS/dataverse/milestones
Now that we’ve published the release, close the milestone and create a new one.
Note that for milestones we use just the number without the “v” (e.g. “5.10.1”).
Add an entry to the list of releases at https://www.iq.harvard.edu/roadmap-dataverse-project
Post a message at https://groups.google.com/g/dataverse-community
Note: this only applies to hotfixes!
We’ve merged the hotfix into the “master” branch but now we need the fixes (and version bump) in the “develop” branch. Make a new branch off the hotfix branch and create a pull request against develop. Merge conflicts are possible and this pull request should go through review and QA like normal. Afterwards it’s fine to delete this branch and the hotfix branch that was merged into master.
Because of the hotfix version, any SQL scripts in “develop” should be renamed (from “5.11.0” to “5.11.1” for example). To read more about our naming conventions for SQL scripts, see SQL Upgrade Scripts.
Please note that version bumps and SQL script renaming both require all open pull requests to be updated with the latest from the “develop” branch so you might want to add any SQL script renaming to the hotfix branch before you put it through QA to be merged with develop. This way, open pull requests only need to be updated once.