Update components for v0.4.0

[dougiesquire]

Update components for v0.4.0

[anton-seaice]

Also I would like it if we document the process to update versions - see #146

[access-hive-bot]

This issue has been mentioned on ACCESS Hive Community Forum. There might be relevant details there:

https://forum.access-hive.org.au/t/cosima-twg-meeting-minutes-2024/1734/16

[anton-seaice]

  * We will need to decide which repos we fork and come up with a management plan for our forks

https://github.com/ciCE-Consortium/cice uses squash commits. I don't think there is a model to have ACCESS specific commits and update from the cice main branch which doesn't involved re-applying the commits on top of the cice main. e.g.

• If you branch from cice main, and then apply some commits, then merge the access commits into cice main and then try and update the access fork, you will have the commits applied plus the squashed commit from PR into cice main ? I think this is what NOAA do
• If you rebase your local fork from cice main instead, then every so often you will have to rewrite the history of the local fork. I think this is what CESM do. The problem with this model is it is hard to follow the history of main (i.e. its not on the commits anymore and not linear!) To avoid rewriting main I guess we could make a new branch everytime we update from upstream.

Anyway, no good suggestions from me on how to handle this !

[anton-seaice]

Extra also, has there been any discussion on using OpenMPI 5.x.x instead of OpenMPI 4.x.x ?

[dougiesquire]

• If you rebase your local fork from cice main instead, then every so often you will have to rewrite the history of the local fork. I think this is what CESM do. The problem with this model is it is hard to follow the history of main (i.e. its not on the commits anymore and not linear!) To avoid rewriting main I guess we could make a new branch everytime we update from upstream.

We definitely do not want to be rewriting history of "public" branches

[dougiesquire]

Extra also, has there been any discussion on using OpenMPI 5.x.x instead of OpenMPI 4.x.x ?

Not that I know of

[anton-seaice]

I think the fix for parallel reads through symlinks on lustre has been done in 5.x.x (open-mpi/ompi#12141)

[dougiesquire]

I think the fix for parallel reads through symlinks on lustre has been done in 5.x.x (open-mpi/ompi#12141)

Nice, we should test this