...
- Mark the release issue as in-progress in JIRA, make sure it has the expected fix version
- Create a temporary branch for the release from the head of the mainline (usually named master). The name should include the JIRA issue identifier and the version to be released, e.g
MODUSERS-245-release-17-3-0 - Check that the current version (as a pre-release) matches the intended release version e.g.
17.3.0-SNAPSHOTmatches17.3.0 - Update the
news.mdfile with changes included in the intended version that are relevant to the users or operators of the system e.g. changes to interfaces provided or required. Where relevant, each line should include a reference to a JIRA issue - (Optional) replace the issue identifiers in the news with links. Adam Dickmeiss provided a script to do this:
sed "s@\([ (]\)\([A-Z][A-Z][A-Z]*-[0-9][0-9]*\)\([ )]\)@\1[\2](https://issues.folio.org/browse/\2)\3@g" < NEWS.md
- Run
mvn release:preparelocally, remember to change the next release version to the next minor version e.g.17.4.0instead of patch version as suggested - Compare the branch to the head of mainline, making sure that the news and next version are as expected
- Raise a pull request for the temporary branch e.g. for mod-users 17.3.0
- Only when the branch and pull request builds have succeeded, push the tag generated by the release preparation
- Build the release tag in Jenkins e.g. for mod-users 17.3.0
- Create a github release including the changes from the news file e.g. for mod-users 17.3.0
- Merge the pull request (and delete the temporary branch)
- Mark the version as released in JIRA. Should include link to github release. Will need to override open issues as the release issue will still be open
- Create new patch (e.g.
17.3.1) and minor (e.g.17.4.0) or major (e.g.18.0.0) versions for potential future releases (as not all developers have permissions to create versions) - Announce the release in #releases Slack channel, including a link to the github release e.g. for mod-users 17.3.0
- Close the release issue in JIRA
...