start doing quarterly(-ish) versioned releases

[edwardhartnett]

Description

Like other software packages, fv3atm should have versioned releases.

Solution

We need to pick a version number to start with, and do a release. Then we need to do quarterly releases thereafter.

Alternatives

The alternative is what we are now doing: unlabeled, undocumented releases via submodule hash.

Testing:

No testing needed to do the first release. In future releases, unit testing will be added.

Dependent PRs:

Required to support documentation and testing efforts.

[DusanJovic-NOAA]

fv3atm currently has versioned releases based on which production system it is used for (for example GFS) or which public release (ufs-wm or ufs-srw) etc. Who is going to use these quarterly releases? And how? Did anyone request these quarterly releases (NCO or ufs-community)? If so, then they should tell us what version numbering scheme they want to use.

Are submodules used by fv3atm going to make release with exactly the same version, with correct commit hashes (atmos_cubed_sphere, ccpp-physics, ccpp-framework and upp)? We must update the corresponding submodules before making a release/tag. Which means we must coordinate that release with code managers of those projects.

[edwardhartnett]

This is part of adding documentation and unit testing to fv3atm. Regular and frequent releases are an agile practice.

Is there some reason that fv3atm cannot have a release, with version numbers, like all other software packages do?

We do not have to update anything before this release, the point is to get a release before we start doing any testing.

Each component should and must have it's own versioning. Just like netcdf-c, HDF5, in fact, every software package you've ever heard of. We have this right now, but we use a hash instead of a version number, and we don't document the release. Instead, we will document a release each time we need to move the ufs_weather_model hash of fv3atm.

Yes, releases must be coordinated by code managers. That is the job of code manager. If doing a release takes more than 5 minutes, the code manager is doing it wrong. I will give a presentation on the agile release process...

Perhaps this confusion stems from the fact that you are used to a lot of manual or system-level testing before a release. Instead, we will do a release without any such testing. However, the next release after this will start to include unit tests.

Eventually we will be releasing fully-tested releases, and then we will run those tests on spack install, so spack and the EMC/NCO install team will be using these releases to work out that solution. If we convince the UFS steering committee not to use submodules, but instead to use libraries, we will be ready to transition fv3atm to a library instead of a subcomponent.

[DusanJovic-NOAA]

Instead, we will document a release each time we need to move the ufs_weather_model hash of fv3atm.

We 'move the ufs_weather_model hash of fv3atm' every time we make a commit to fv3atm, which is sometimes multiple times a week. Are you suggesting that we make a release with new version number multiple times a week. That could be hundreds of releases a year? What's the purpose of all these releases when ufs-weather-model must still know exact hash for it's fv3atm submodule.

[DusanJovic-NOAA]

If we convince the UFS steering committee not to use submodules, but instead to use libraries

Why would we do that? That will mean that any change in any of the subcomponents will require a new library build. Who is going to do all those library builds? How? Where are we going to store all these library rebuilds? How is ufs-weather-model going to 'find' all those libraries?

[WenMeng-NOAA]

UPP was previously configured as a library for inline post in the UFS-Weather-Model. The library team required quarterly releases for UPP library installation, which significantly slowed down UPP development to support GFS, RRFS, GEFS, and HAFS, AQM implementations—until Dusan updated the configuration to make UPP a submodule of fv3atm.

[BrianCurtis-NOAA]

I will put my support behind the move towards the agile development. It's what everyone else does, so we should be there as well.

To answer the question on the builds, I think that process is (can be) mostly if not completely automated through CI/CD which Github has capabilities for. For example, once the button is clicked to release then a bunch of actions start working on providing artifacts from the build for the public to use and saves it in github (please correct me if I'm wrong).

@edwardhartnett After a "first release" what pieces/methodologies would need to be in place? How would the CM workflow need to change towards Agile. Maybe painting the picture a bit might help?

[edwardhartnett]

Wow, great discussion.

@BrianCurtis-NOAA you're correct, I have not fully explained this issue. We have a meeting to discuss this topic week after next; I will add you to the invitation list. I have a slide which explains the release process and why we do it. (And we can meet in person, since I will be in Collage Park for the meeting.)

@WenMeng-NOAA I would not expect improvement from making untested code into a library. Without the ability to test, the library brings little benefit. This is why all modern libraries use unit testing. However, it's not clear to me how doing releases can slow other development - a release takes only a few minutes to do. How did this slow other development? Manual testing?

Also, there was no time at which the libraries team required quarterly releases. UPP has only done two versioned releases, 10.0.0 and 11.0.0 in May and June of 2022.

@DusanJovic-NOAA if we move the hash every week, then indeed we should not do new versions every time. I presented about spack and how the UFS will be installed on WCOSS2, no longer with a set of manually executed git commands, but with spack. So spack will install all libraries, as well as the model and all submodules.