Curating a Release#

Code Review Deadline#

In the weeks leading up to the deadline, announcements should be made on the Simulation Systems Discussion Board to remind the community of the upcoming deadline.

Shortly after the deadline Issues that are not in review should be removed from the milestone. This is done here to give the assignees time to assess their work before the release happens.

python SimSys_Scripts/gh_review_project/cr_deadline.py --milestone=<title>

with an optional argument ``--dry`` to dry run the changes before doing them
for real.

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. One will have developed the release branch and the other will review it (developer and reviewer below). It’s also worth making sure both people have signed the relevant CONTRIBUTORS file - do this in a separate PR first if not.

  • Before starting, an admin on the repository will need to update some rulesets:

    • prevent_updates

      • Set stable as an excluded branch

    • main

      • Disable the Require Linear History setting

      • Set the only allowed merge method as merge (remove squash)

  • 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.

    If there have been any changes to the CONTRIBUTORS file during the release, the CLA Check action will fail in this PR. It is not a required status check when merging to stable so it can be safely ignored.

  • 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

  • The reviewer can now merge the second PR.

  • The admin must now revert the 2 settings above in main and remove the exception for stable in the prevent updates ruleset from earlier.

  • Tag the release.

Hotfix Release#

This section describes the process of applying a hotfix to the most recent release. This section is relevant for all repositories with a stable and main branch setup. The hotfix process will be completed by 2 people with commit privilege to the relevant repository. One will have developed the hotfix branch and the other will review it (developer and reviewer below).

  • Before starting, an admin on the repository will need to update some rulesets:

    • prevent_updates

      • Set stable as an excluded branch

    • stable

      • Set the only allowed merge method as squash (remove main)

    • main

      • Disable the Require Linear History setting

      • Set the only allowed merge method as merge (remove squash)

      • Disable the Require branches to be up to date before merging setting (if commits have been pushed to main since the release, this would require stable to be updated with those, which isn’t desired).

  • The developer will make the hotfix change, making sure the branch has been created from stable. Open a PR for this change targetting stable and get it reviewed and committed. The reviewer should squash this change into stable.

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

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

  • The reviewer can now merge the second PR.

  • The admin must now revert the ruleset changes made above.

  • Tag the hotfix.

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, switch to the commit that you would like to create a tag from (probably git switch stable):

    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.

    • Follow the instructions for 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

Release Notes#

Dependencies These should be prepared just before the release, ready to be included with each release.

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#

Updating Standard Suites#

Dependencies UM + Apps Releases

Stash Browser#

Dependencies UM Release

UMDP Release#

Dependencies UM Release, Standard Suites Upgrade

Milestones and Projects#

Dependencies All Releases

Standard Jobs and Wiki Pages#

Dependencies UM + Apps Releases

GitHub and Shared Account Permissions#

Dependencies None