micromamba/mamba --version displays pre-release version names + establishes pre-release versions name scheme

[Klaim]

Part of the effort for #3638

While I started this just to allow displaying the pre-release versions in micromamba/mamba --version, this required also changing the release scripts to provide the relevant information to the source code. As part of that change I setup the discussed pre-release version naming scheme with validation in the release scripts.

Also deprecates mamba::version_arr() and umamba::version_arr() functions which seem unusued. If there is a need for information about the version, I'll add another more precise function as a replacement, or we'll just remove these.

[Klaim]

Note that this version accepts a minimum of 3 dot-separated fields but does not limit the number of dots over 3, so schemes with and without additional dots are considered "valid" by the validation script.

[Hind-M]

What about rc and dev?

[Hind-M]

Adding this as a reference.

[jjerphan]

Adding this as a reference.

This piece of conda.models.VersionOrder's docstring is also relevant (it is linked in the section Hind shared).

[JohanMabille]

This PR does not include the changes so that umamba --version shows pre-release versions, right?

[Klaim]

This PR does not include the changes so that umamba --version shows pre-release versions, right?

It does (if it doesnt, its a bug in this pr): --version is implemented there and implemented in terms of the define which is generated by the scripts modified here.

In the previous code, the version name was parsed, the major minor and patch number were extracted, then the version string define was re-built from that. In this PR we just print the validated name that was used, so it will be whatever you passed to the script as long as it has been validated.

Note that it's not visible in this PR because I didnt use a pre-release version, but if you want I can use it with -dev1 as we are in development versions right now, to make it very clear from the CI?

[Klaim]

For clarity and because it's one of the intended usage, I added a commit that sets the version to 2.0.5.dev0
It is important to note that to do that I had to run the release scripts and then remove the generated changelogs. I think it would be useful to modify (in another PR) release.py to be called standalone (currently it relies on the modified changelog from update_changelog.py and make it allow just changing the version in the generated headers without changing anything else, to be able to switch the version to devN just after a release.
Another future improvement would be to have a way to add the commit id to a dev version, so that we can identify which commit matches the micromamba binary, in case someone uses such binary and reports issue. Anyway that's future improvements.

[Klaim]

I just realized that the cmake scripts are taking the version name from the major.minor.patch numbers only, so cmake believes this is 2.0.5. @JohanMabille @jjerphan Should I fix that in this PR or another one?

[Klaim]

@JohanMabille Confirmed that version name is complete in micromamba --version : https://github.com/mamba-org/mamba/actions/runs/12158203081/job/33905615645?pr=3639#step:10:13

[JohanMabille]

@JohanMabille Confirmed that version name is complete in micromamba --version : https://github.com/mamba-org/mamba/actions/runs/12158203081/job/33905615645?pr=3639#step:10:13

Yeah my bad, I misread the code.

[JohanMabille]

I just realized that the cmake scripts are taking the version name from the major.minor.patch numbers only, so cmake believes this is 2.0.5. @JohanMabille @jjerphan Should I fix that in this PR or another one?

I think it can be done in a dedicated PR

[Klaim]

Note that I've re-launched already 3 times the failing CI run with the vcpkg command (which failed so far when trying to acquire a package); not sure what's going on exactly.

[JohanMabille]

This was a vcpkg issue, not related to mamba.