Release management: version string and components

[mo-marqh]

PR Summary

Sci/Tech Reviewer: Andrew Coughtrie (@andrewcoughtrie)
Code Reviewer: James Bruten (@james-bruten-mo)

version numbering and string return function added to lfric_apps

• Release management: version string and components lfric_core#340
• this will require a PR on the Simulation Systems docs for Release management (James Bruten (@james-bruten-mo) )

Code Quality Checklist

• I have performed a self-review of my own code
• My code follows the project's style guidelines
• Comments have been included that aid understanding and enhance the readability of the code
• My changes generate no new warnings
• All automated checks in the CI pipeline have completed successfully

Testing

• I have tested this change locally, using the LFRic Apps rose-stem suite
• If any tests fail (rose-stem or CI) the reason is understood and acceptable (e.g. kgo changes)
• I have added tests to cover new functionality as appropriate (e.g. system tests, unit tests, etc.)
• Any new tests have been assigned an appropriate amount of compute resource and have been allocated to an appropriate testing group (i.e. the developer tests are for jobs which use a small amount of compute resource and complete in a matter of minutes)

trac.log

Test Suite Results - lfric_apps - lfric_apps_version/run4

Suite Information

Item	Value
Suite Name	lfric_apps_version/run4
Suite User	mark.hedley
Workflow Start	2026-04-22T08:06:58
Groups Run	developer

Dependency	Reference	Main Like
casim	MetOffice/casim@2026.03.2	True
jules	MetOffice/jules@2026.03.2	True
lfric_apps	mo-marqh/lfric_apps@lfric_apps_version_m	False
lfric_core	mo-marqh/lfric_core@4b6d2de	True
moci	MetOffice/moci@2026.03.2	True
SimSys_Scripts	MetOffice/SimSys_Scripts@4387949	True
socrates	MetOffice/socrates@2026.03.2	True
socrates-spectral	MetOffice/socrates-spectral@2026.03.2	True
ukca	MetOffice/ukca@2026.03.2	True

Task Information

✅ succeeded tasks - 1185

Security Considerations

• I have reviewed my changes for potential security issues
• Sensitive data is properly handled (if applicable)
• Authentication and authorisation are properly implemented (if applicable)

Performance Impact

• Performance of the code has been considered and, if applicable, suitable performance measurements have been conducted

AI Assistance and Attribution

• Some of the content of this change has been produced with the assistance of Generative AI tool name (e.g., Met Office Github Copilot Enterprise, Github Copilot Personal, ChatGPT GPT-4, etc) and I have followed the Simulation Systems AI policy (including attribution labels)

Documentation

• Where appropriate I have updated documentation related to this change and confirmed that it builds correctly

PSyclone Approval

• If you have edited any PSyclone-related code (e.g. PSyKAl-lite, Kernel interface, optimisation scripts, LFRic data structure code) then please contact the TCD Team

Sci/Tech Review

• I understand this area of code and the changes being added
• The proposed changes correspond to the pull request description
• Documentation is sufficient (do documentation papers need updating)
• Sufficient testing has been completed

(Please alert the code reviewer via a tag when you have approved the SR)

Code Review

• All dependencies have been resolved
• Related Issues have been properly linked and addressed
• CLA compliance has been confirmed
• Code quality standards have been met
• Tests are adequate and have passed
• Documentation is complete and accurate
• Security considerations have been addressed
• Performance impact is acceptable

[iboutle]

I've certainly no issue with this, but I'm also not sure I should really be the code owner for this - I'm not sure if that means the file is in the wrong place - it doesn't feel like this is a science constant (certainly the science doesn't care about the revision number - in fact we explicitly mandate that the science is independent of the revision number). I'm not sure if there is somewhere else more suitable we should put it?

[mo-marqh]

I've certainly no issue with this, but I'm also not sure I should really be the code owner for this - I'm not sure if that means the file is in the wrong place - it doesn't feel like this is a science constant (certainly the science doesn't care about the revision number - in fact we explicitly mandate that the science is independent of the revision number). I'm not sure if there is somewhere else more suitable we should put it?

I think you're right iboutle, that this code is in the wrong place.

I propose that we move the code to sit alongside space_from_metadata and thus rename science/shared/vector_space to something like science/shared/utilities and reflect this in

[iboutle]

I've certainly no issue with this, but I'm also not sure I should really be the code owner for this - I'm not sure if that means the file is in the wrong place - it doesn't feel like this is a science constant (certainly the science doesn't care about the revision number - in fact we explicitly mandate that the science is independent of the revision number). I'm not sure if there is somewhere else more suitable we should put it?

I think you're right iboutle, that this code is in the wrong place.

I propose that we move the code to sit alongside space_from_metadata and thus rename science/shared/vector_space to something like science/shared/utilities and reflect this in

That seems better - it still seems odd that it's in a top-level location called "science", but we don't really have anything like "control" or "infrastructure" in lfric_apps, which would seem like the more natural place for something like this to sit

[Andrew Coughtrie (andrewcoughtrie)]

A good change just the one question to answer and perhaps change but nothing major.

[Andrew Coughtrie (andrewcoughtrie)]

is there any chance there is going to be a need to have incremental dev versions between releases? if so _dev0 might be better that way it is obviously incrementable when needed (is a pretty standard mechanism as well).

[mo-marqh]

I discussed this with James Bruten (@james-bruten-mo)

there is a follow up activity to document these behaviours in the working practices, that James is going to do as soon as this is approved.

At present there is no _dev working practice, so this is new, and we can agree to do what we think is best. I think the simpler option is to have a singular _dev suffix that is unchanging, and only indicates that this is not a release, it's somewhere in the code commit line between releases, or even on a branch.

I propose that we stick with this singular _dev suffix, and only adopt some sort of increment if we come up with a managed working practice to support it.
At present the only working practice is on releases, and that needs a bit more systems documentation to make facets explicit.

[Andrew Coughtrie (andrewcoughtrie)]

Yep that's fine, I'm happy to leave it as is if this is the choice we are making 😸