2026.03.1 Release

[Jenny Hickson (jennyhickson)]

Dear All,

We are pleased to announce the 2026.03.1 release of the Simulation Systems repositories. All repositories¹ have also been tagged with 2026.03.1 🎉 and this release includes:

• LFRic vn3.1 (Apps and Core)
• UM vn14.1
• JULES vn8.1

Many thanks to all who contributed developments and reviews.

Jenny, on behalf of SimIT

Footnotes

1. LFRic Apps, LFRic Core, UM, JULES, UKCA, MOCI, CASIM, SOCRATES, SOCRATES-Spectral, UM Meta, UM Aux, UM Doc ↩

[iboutle]

Great stuff, many thanks!

One question - once I've updated 'stable' on my fork, how do I then create branches from old stable releases (e.g. vn3.0)? Is it possible to pull each tagged release into the fork as separate entities?

Can we also encourage people to cut new branches from the new release and merge old branches in, rather than merging stable into the branches - this will then leave branches from the old stable release available for use in standalone suites (this is especially important if the old branch ever requires updating, which can't be done if stable has been merged in).

[James Bruten (james-bruten-mo)]

Hi Ian,

The git switch -c command will take any commit hash/tag/branch, so you can do git switch -c vn3.0 to create a vn3.0 branch.

For keeping changesets available across old versions, yes people are welcome to do this by creating a new branches. However, it is better to have one branch with a continuous set of development (for example, you can't change the source branch of a PR). So we'd recommend:

• Keeping a primary branch which gets updated from stable at each release
• For testing at an old version, the commit hash before stable was merged can be used
• If an old version needs updating then a branch can be taken from that commit hash and development continued there

This can be done even after merging on stable as the history of each branch will always* be available. This means you can get the hash of the commit before the upgrade from the branch log, and create a new branch from that, even if stable has been merged in.

* This assumes the branch hasn't been rebased which will rewrite the history - this is why we recommend never rebasing for the SimSys repos

[Andrew Coughtrie (andrewcoughtrie)]

If you want all the tags to also appear on your fork you'll have do the following (this will need to be done after each release to keep them up to date).

1. Check what your remotes are in your local clone of your fork by doing git remote -v, if you only have origin you'll need to do the following - git remote add upstream git@github.com:metoffice/lfric_apps, this will add a remote called upstream pointing at the main Met Office repo, you can then do step 2.

2. If you already have a remote called upstream pointing to MetOffice/lfric_apps can do the following.:
   git fetch --tags upstream
git push --tags

[MichaelWhitall]

I agree, making a separate branch from each release of stable is needed for any change that we want to test in other suites outside of rose-stem. The branch we attach to a pull-request will have to have latest changes from main merged into it before it gets committed, so won't remain valid at a stable release version (which is required for use in rose workflows used for science testing!) So I'm making a tedious (and I'm sure frowned-upon) habit of maintaining multiple versions of my branches, one defined at each stable release, and then one that tracks the head of main, to submit in the pull-request. I then do all my developments at the oldest stable release version of the branch, then merge all the changes forwards to the other branches. e.g. see this issue (MetOffice/lfric_apps#178), where I list the branches at each stable release, distinct from the one in the pull-request :P

Cheers!
Mike