These are the steps involved in performing a Mantid patch release. To perform a full release look at the release checklist.

Request

Authorisation

Development

The patch release will be prepared based off the branch used to construct to most recent major point release, e.g. release-v3.9 would be used for any 3.9.x patches.

Changes for the patch should be made using the standard GitHub workflow for merging code with master. The issue and pull request should then have the PatchCandidate label applied to them. These commits will then be cherry picked from master 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 /blob/release-vX.Y/buildconfig/CMake/VersionNumber.cmake#L9, where X.Y should be replace with the appropriate numbers.

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:

Once cherry picked the milestone of the original pull request should be updated to the patch milestone.

Nightly Builds

The Jenkins 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. 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:

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: