Patch Release Checklist¶
These are the steps involved in performing a Mantid patch release. To perform a full release look see Release Checklist.
Request¶
Anyone may request a patch release, but that request must be intially approved by one of the local PMs.
Development¶
The patch release will be prepared based off the tag used to mark
the last minor release. A branch called release-next
will be created from this tag.
Changes for the patch should be made using the standard GitHub
workflow for merging code with main
. The issue and pull request should then have the PatchCandidate
label applied to them. These
commits will then be cherry picked from main
on to the release branch.
Release Branch¶
The release branch will currently have its version fixed to exact version of the last major/patch release. It is not a requirement but advised to unfix the patch number while the patch is being compiled. This prevents the nightly builds from generating a collection of packages that have exactly the same version. The patch number can be unfixed by commenting the line in https://www.github.com/mantidproject/mantid/blob/release-next/buildconfig/CMake/VersionNumber.cmake#L9.
Release Notes¶
Once the patch version has been unfixed the main reviewer should create a skeleton set of patch release notes on the release branch using the python helper tool.
Cherry Picking & Code Review¶
It is the job of the main reviewer of the release to review each
issue/pull request marked PatchCandiate
and decide if the risks of
the changes are low enough to include in a release that will not
undergo full beta testing by scientists. If it is acceptable then on the release branch for each pull request:
find the list of commit
SHA1
values in that pull requestcheck if any of these commits has altered the release notes for the next major release
if not then pass all commits in the order oldest->newest to
git cherry-pick -x
if release notes were modified in a commit on their own then pass all commits except this one in the order oldest->newest to
git cherry-pick -x
if a commit has a mixture of code/release note changes then:
pass the list of commits up to but not including this commit to
git cherry-pick -x
now pass this single commit to
git cherry-pick -x -n
and it will not make a commit. Remove the major release note changes and commitgit add
/git commit
if there are any remaining commits after this then pass them to
git cherry-pick -x
as before.
finally add a commit that updates the patch release notes with this pull request link and description in the table.
Once cherry picked the milestone of the original pull request should be updated to the patch milestone.
Nightly Builds¶
The release pipeline contains jobs that check for changes on the current release branch each night (00:00 GMT). Any detected changes will cause a clean build of the code followed by a run of the system tests. The Linux clean builds should have the PACKAGE_SUFFIX set to nightly while testing the patch.
These jobs should be checked each morning to confirm that everything is green.
Release Day¶
On the day of release a few steps are required:
update the patch version:
navigate to https://www.github.com/mantidproject/mantid/blob/release-next/buildconfig/CMake/VersionNumber.cmake
edit the
VERSION_PATCH
to the required number for the patch and commit the resultrun a manual build of all of the OS jobs under {{ site.mantidreleasebuilds }} and when asked for a suffix use an empty string
wait for the builds to finish (will take more than 1 cup of tea/coffee/beverage of choice)
While waiting for the builds create a new release on GitHub, using a tag
of the form v.X.Y.Z
and populate with information from the release
notes (see a previous version of the format).
Once the builds complete have the development team run unscripted testing on the packages generated by the clean release builds. In particular the issues intended to be fixed should be tested.
Once the testing has passed:
Use the manual deploy job at release pipeline to deploy packages and documentation to the public web.
The windows binary will not be deployed and must be signed by someone at ISIS and uploaded to sourceforge manually
Put packages on GitHub
RHEL 7 only: Build the suffix-package
mantidXY
by running another clean RHEL 7 build from the release pipeline but use the suffix XY, whereX
is the major version andY
is the minor version (currently used at SNS)Create new DOI using the scripts in the codebase and instructions on release checklist.
Open a PR to update the relevant metadata in the
CITATION.cff
file as explained in the release checklist.Send an email, including the text of the release notes, to the following lists
nobugs@nobugsconference.org
news@neutronsources.org
neutron@neutronsources.org
Also post the contents of the message on Announcements on Slack
Add topic to the news page on the forum
Close the release milestone in github
Remove the patch candidate tag from pull requests (if not already done)