Move version from YYYY.0M.MICRO to YYYY.MINOR.MICRO

[Hofer-Julian]

Some implementations trim the 0 at the beginning, which makes it harder to test things.
https://dpcbuild.deltares.nl/buildConfiguration/Ribasim_Windows_TestRibasimApi/3306663?buildTab=log&linesState=165.206.233&logView=flowAware&focusLine=190

[visr]

Ok I have been thinking about this more than I probably should. I'm still glad we have a YYYY and the same version for all components, so let's think about good options for the rest.

Regarding the linked build failure, we can of course easily return a non-stripped version with ribasim --version. We cannot stop external tools like pip and conda from stripping.

YYYY.MM.MICRO (2024.2.0)

• no pip/conda/julia stripping the leading zero, so always consistent

YYYY.0M.MICRO (2024.02.0)

• sorts nicely as a string
• like xarray
• more recognizable as a month (for most of the year)

Other Deltares software with calender based versions

• Delft3D FM Suite 2023.02
• Delft-FEWS 2020.02
• D-Stability 2024.01

The other Deltares software that starts with YYYY is something like YYYY.0MINOR, in that the second part is not a month, just a sequential number in the year, starting at 1, which is often max 2, but they still add a leading zero. I haven't really checked if they use a MICRO part, or just mention the build number somewhere.

Perhaps not using months is not such a bad idea. I can imagine at some point:

• Wanting to release a breaking change or new feature in the same month, meaning we need to wait to next month or use the MICRO part for that, both not great solutions.
• Needing to provide new bugfix releases for past versions, for which it would be nice to keep MICRO only for bugfixing, as a patch number.

It is nice to see the release month from the version, but consistency with other Deltares software and my point above is also important. I could see us having 10 MINOR versions in one year, and just one or two in another year. I suggest to use the MICRO version as well, though for many purposes communicating only the year and minor version (as the other Deltares software) would be sufficient, unless you are dealing with bugs.

https://calver.org/

[Hofer-Julian]

@visr and I now agreed on YYYY.MINOR.MICRO following pip's version scheme.
The PR doesn't have to be adapted for this.

[visr]

The release docs do need updating.

[Hofer-Julian]

The release docs do need updating.

Ah yes, nice find.
Updated the docs.