Contents:
Use the number of the milestone with a “v” in front for the release tag. For example: v4.6.2
.
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:
Increment the version number to the milestone (e.g. 4.6.2) in the following two files:
Add the version being released to the lists in the following two files:
Here’s an example commit where three of the four files above were updated at once: https://github.com/IQSS/dataverse/commit/99e23f96ec362ac2f524cb5cd80ca375fa13f196
... into the release branch, make a pull request and merge the release branch into develop.
The “develop” branch should be merged into “master” before tagging. See also the branching strategy described in the Version Control section.
Developers should 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 5053-apis-custom-homepage.md
.
At or near release time:
/doc/release-notes
and write the release notes, making sure to pull content from the issue-specific release notes mentioned aboveUpload the following artifacts to the draft release you created:
mvn package
from Jenkins)cd scripts/installer && make
)Click the “Publish release” button.
Previous: Docker, Kubernetes, and OpenShift | Next: Tools