Add some way to version this model from within the `spack.yaml`

CodeGat commented 6 months ago

We are using YYYY.0M.MINOR to version our spack deployments. The COSIMA/access-om3 repo uses a different versioning scheme for their model and their spack package. How do we version our spack deployments, and where can we put this information? How do we reconcile the versioning of COSIMA/access-om3 with our own one?

CodeGat commented 6 months ago

Just for our discussion tomorrow :)

CodeGat commented 5 months ago

So we had a resolution with @aidanheerdegen and @harshula s help!

For background information, access-om2 the SBD (which self-referentially points to https://github.com/ACCESS-NRI/ACCESS-OM2, which contains no code and is essentially a 'deployment' repository similar to https://github.com/ACCESS-NRI/payu-condaenv) was able to be versioned as the overall deployment (as seen here https://github.com/ACCESS-NRI/ACCESS-OM2/blob/main/spack.yaml#L8)
access-om3 the SPD (which points to the codebase COSIMA/ACCESS-OM3) will be versioned, but we will stick to the existing convention in COSIMA/ACCESS-OM3 - namely, versions like 0.2.0. We do not want to tie the version of the deployment (which contains information not only about the codebase but also things like spack-{packages,config}, dependency changes, etc) to be the version of the codebase.
Since access-om3 is an SPD and not an SBD, it cannot be the version of the entire deployment (which is in YYYY.0M.MINOR format).
In that case, we should have a root access-om3-bundle (name pending) SBD that can be versioned in a similar way to the access-om2 SBD.
This should be the case for all future models that have a SPD as the root element - have a root SBD (like <model>-bundle) above that, that can be the version for the entire deployment.

All in favour, say 'Aye!'

aidanheerdegen commented 5 months ago

Aye aye! ☠️ 🏴‍☠️

Possible naming conventions:

<model>-meta
<model>-hybrid
<model>-bundle

micaeljtoliveira commented 5 months ago

Just trying to understand a bit the context and the issue.

From what is written above I deduce that the version number of the releases in https://github.com/ACCESS-NRI/access-om3 need to be identical to the version of OM3 you are releasing. Is this correct? If so, why is that? Is it because this is an assumption built in the CI/CD?

Otherwise I would have just expected that releases in https://github.com/ACCESS-NRI/access-om3 can be whatever you want, as long as there is a one-to-one mapping between them and the version of OM3.

Edit: to put it in another way. Why can't you simply pin the version of OM3 here?

Edit 2: thinking further about this, the mapping between the NRI release and the version of OM3 should not be bijective. The only requirement is that to each NRI release corresponds only one version of OM3, which is trivial.

CodeGat commented 5 months ago

Hey Micael! :)

From what is written above I deduce that the version number of the releases in https://github.com/ACCESS-NRI/access-om3 need to be identical to the version of OM3 you are releasing.

No - it's the opposite case we need. access-om3 the package (and associated codebase) can be versioned separately as it currently - we don't want to change any of that. We want to be able to version access-om3 plus everything else associated with a deployment.

Why can't you simply pin the version of OM3 here?

We will be. But the overall version of the deployed release is more than just the version of access-om3 (the codebase) that it is built with, and we want this somehow reflected in the spack.yaml itself. We want to be able to version changes to the spack.yaml, the versions of spack-packages and spack-config bundled with the deployment, etc. ACCESS-OM2 is versioned in this proposed way (although that is because there is no access-om2 SPD to begin with).

So we will need to have a SBD that can act as this 'overall' version.

micaeljtoliveira commented 5 months ago

But the overall version of the deployed release is more than just the version of access-om3 (the codebase) that it is built with, and we want this somehow reflected in the spack.yaml itself. We want to be able to version changes to the spack.yaml, the versions of spack-packages and spack-config bundled with the deployment, etc. ACCESS-OM2 is versioned in this proposed way (although that is because there is no access-om2 SPD to begin with).

So we will need to have a SBD that can act as this 'overall' version.

Okay, I understand that you want to version the whole deployment. I just assumed that was the version of https://github.com/ACCESS-NRI/access-om3

So the issue is simply that you want to have a version number corresponding to the whole deployment in the spack.yaml itself?

CodeGat commented 5 months ago

Correct! The current thinking is that we use a SBD (as we did in ACCESS-OM2) to be this overall version. That way we can still pick out the versions access-om3, dependencies, etc as part of the packages section (similar to the ACCESS-OM2 spack.yaml).

micaeljtoliveira commented 5 months ago

That way we can still pick out the versions access-om3, dependencies, etc as part of the packages section (similar to the ACCESS-OM2 spack.yaml).

Sorry, I'm not sure I understand this bit. Why do you need an SBD to specify the dependencies' versions? These are already defined in the packages section of the current OM3 spack.yaml :confused:

CodeGat commented 5 months ago

Ah, correct. Got my wires a little crossed there - the spack.yaml was what I meant. Sorry!

CodeGat commented 5 months ago

Closed as we have a way forward with this issue. Continuing updates will be in https://github.com/ACCESS-NRI/ACCESS-OM3/pull/5

ACCESS-NRI / ACCESS-OM3

Add some way to version this model from within the `spack.yaml` #3