Procedure for making new supported configurations

[anton-seaice]

It's currently unclear what the best way is to make new dev- and release- branches.

Mostly, we seem to branch from existing dev- and release- branches, which works ok but some details are unclear or forgotten:

• what should metadata.yaml fields be set to? Should we always delete version when creating new branches?
• what other fields need setting when initially creating branches (e.g. jobname ?)

Having the out of date information in metadata.yaml is problematic ... it leads to experiments with incorrect metadata.

Is it possible to programmatically enforce anything about this ? Otherwise I guess we just need to write a procedure on steps when making new branches.

Related but possibly separate, it's good for provenance to be able to do configuration releases using the PR workflow, but it tends to try to compare to tags which were created BEFORE the new branch was forked off:

e.g.

ACCESS-NRI/access-esm1.6-configs#811 (comment)
ACCESS-NRI/access-om3-configs#947 (comment)

Those two links try to compare checksums against tags which are not prefixed by release-. I wonder if the workflow should only compare against tags which match the branch name (e.g. tags of the form release-<config_name>-* )