Curating a Release#

Release Issue#

Open a Release Curation Issue in the git_playground, using the release Issue template.

Stable + Main Release#

This section describes the process of merging main and stable. It assumes that any required release changes have already been merged into main and that all sources in the dependencies.yaml file are as they should be. This section is relevant for all repositories with a stable and main branch setup.

The release process will be completed by 2 people with commit privilege to the relevant repository, at least one of whom must be an admin. One will have developed the release branch and the other will review it (developer and reviewer below).

  • The developer should open a PR directly in the MetOffice repository by going to the Pull Requests tab and selecting the New Pull Request button. Target the stable branch.

    ../_images/main_stable_light.png ../_images/main_stable_dark.png

  • The reviewer will then review and commit the PR. When committing the branch, ensure that the merge method is merge. This should be the default for the stable branch as we want to keep the history of main in the stable branch.

  • The developer will then create another new PR as above, to merge the stable branch into main.

    ../_images/stable_main_light.png ../_images/stable_main_dark.png

  • At this point an admin will need to modify the branch protection rules for the main branch, so that the commit can be performed with a normal merge. This keeps main and stable with an identical history.

    • Navigate to the main ruleset.

    • Disable Require linear history.

    • Set merge as an allowed merge strategy and disable squash.

  • The reviewer can now merge the second PR.

  • The admin must now revert the 2 settings above.

Tags and Releases#

  • All repositories will be tagged with the Simulation Systems release tag in the format YYYY.MM.X. * In an upto-date clone of the repository:

    git tag <tag_name>
git push origin <tag_name>

  • If appropriate, a release can be created and tagged,

    • From the GitHub repo, select releases and then Draft a new release.

    • Create a new tag and title the release with the same name, eg. vn14.0.

    • Select to Generate release notes.

    • Then Publish release.

Pre-Release#

UM Test Release#

Dependencies The point of the test release is to test the release system/process works before we have to do it for real. Typically aim for 1-2 weeks before release day. However, before a test release can be done, all changes to fcm-make config files, major rose-stem changes (things like basic upgrade macro or KGO updates don’t necessarily need to be included) and modifications to the release_new_version.py script need to be on main, so this will cause some variation as to when the test release is done from release to release.

Partner Testing#

Dependencies All source code changes must be on main along with any rose-stem changes that affect multiple sites before partner testing can start. Ideally the test release will also have been completed.

Software Stack#

Dependencies Any potential changes to platform software stacks

Main Release#

Shumlib Release#

Dependencies All shumlib PRs

Mule Release#

Dependencies All mule PRs, Shumlib release (if required), UM release (to actually install)

Tag Other Repositories#

Dependencies All PRs for each repository.

Jules Release#

Dependencies Partner Testing, All Jules PRs committed

UM Main Release#

Dependencies All UM PRs, Test Release, Partner Testing, Jules Release

LFRic Apps Release#

Dependencies All LFRic PRs (Apps + Core), Jules Release

Post Release Tasks#

Release Notes#

Dependencies Most of this can be done pre-release but some details of commit hashes will be dependent on the main release being done.

Updating Standard Suites#

Dependencies UM + Apps Releases

Stash Browser#

Dependencies UM Release

UMDP Release#

Dependencies UM Release, Standard Suites Upgrade

Standard Jobs and Wiki Pages#

Dependencies UM + Apps Releases

GitHub and Shared Account Permissions#

Dependencies None