Update the release schedule

[bouweandela]

The current release schedule contains one more release (version 2.3 in June) and then it's finished. We need to update the schedule and extend it with another year or so.

[bouweandela]

My proposal would be to continue with the current 3 releases a year, e.g. v2.4 in October 2021, v2.5 in February 2022, v2.6 in June 2022, but other dates would also be fine with me. Any opinions @ESMValGroup/esmvaltool-coreteam?

[bouweandela]

And we have a release manager for v2.3 🎉 @zklaus will manage the release, supported by @jvegasbsc who did v2.2.

[bouweandela]

There were some concerns raised at the monthly meeting that 3 releases a year would put too much burden on the development community, but there is good hope that we can make this situation much better within the next half a year or so by running all recipes automatically before a release. The scientific part of the review before the release would then mostly consist of looking at the figures (and even that can probably be partly automated, at least by automatically checking if figures look very different from previous releases).

@bouweandela mentioned that the schedule of 3 releases a year is chosen such that new ESMValCore features become available fast enough for ESMValTool development installation, which always uses the latest released version of ESMValCore to provide a 'stable' basis for diagnostic developers to build on. Having a release schedule available soon is important, because @bjlittle promised to try and plan the iris releases at least 2 weeks before the ESMValCore feature freeze, to allow us enough time to adjust.

[jvegreg]

3 releases a year looks good to me. It will be easier as we refine the process with each one.

There is also another thing to consider: if we let too much time to pass between releases, we are more likely to find issues when we actually do them, so the burden of each on is increased.

By the way, with the timed releases approach we are using and as we are already doing some backward incompatible changes, should we abandon semantic versioning and go to calendar versioning? See https://calver.org/

[bouweandela]

should we abandon semantic versioning and go to calendar versioning?

I agree that would make sense from a technical point of view, maybe something to discuss at the next workshop? @ESMValGroup/esmvaltool-coreteam

[zklaus]

Agree with 3 releases per year. Not so sure about abandoning semantic versioning. Perhaps we should rather be clear and explicit about backward-incompatible changes?