Release Process Improvements (for 2.x)

[Klaim]

Troubleshooting docs

• My problem is not solved in the Troubleshooting docs

Anaconda default channels

• I do NOT use the Anaconda default channels (pkgs/* etc.)

How did you install Mamba?

Mambaforge or latest Miniforge

Search tried in issue tracker

N/A

Latest version of Mamba

• My problem is not solved with the latest version

Tried in Conda?

Not applicable

Describe your issue

We started discussing privately this subject so I'm moving the discussion here for making sure we coordinate and detect potential disagreements.

Problems

• We need an established/official workflow to publish pre-release versions before actual releases (at least for minor versions), so that we get some user feedbacks before releasing a version. Recent experiments doing that showed how it helped growing a patch version that was actually fixing the reported issues for the related major version. Establishing at least one alpha and/or beta phase as part of the official release process would help limit publishing releases that have major regressions.
• We dont have an established version scheme to handle pre-release versions (semver allows various ways to do this).
• Our release tooling/scripts doesnt handle correctly the pre-release part of semver.
• micromamba/mamba --version with a pre-released version (for example v2.0.4alpha1) is not
• The current release process will generate multiple tag for 1 version, one of the tag being the date of the tagging. I believe it was historically established because of a stronger separation between mamba and libmamba, but current context implies that both behavior are very much related as mamba/micromamba is just a driver for libmamba at this point (it doesnt relay on any conda code anymore). Therefore in the current context, multiple tags for the same version feels overkill. The date tag is also apparently unnecessary (please ping us if you have a use for it).

Solutions

These are the different points we already briefly discussed and started working on to solve these problems:

• Decide on a pre-release naming scheme: we decided to go with X.Y.Z-prerelease_type.increment with the increment separated by a . so that it is easy for (future) tooling to compare/order pre-release versions. For example 1.2.3-alpha.0 or 2.1.0-beta.1
v1.2.3.alpha0 , see discussion below.
• Make the release scripts handle (and validate) the new version schemes (I'm working on it micromamba/mamba --version displays pre-release version names + establishes pre-release versions name scheme #3639)
• Make mamba/micromamba --version display the pre-release part when it is a pre-release version (I'm working on it micromamba/mamba --version displays pre-release version names + establishes pre-release versions name scheme #3639)
• Establish a release process that starts with publishing an alpha or beta first (briefly discussed, nothing established yet). This requires some documentation of that process and maybe tweaking the release script to reflect it

mamba info / micromamba info

N/A

Logs

N/A

environment.yml

N/A

~/.condarc

N/A

[wolfv]

The version schema you chose is not compatible with conda versioning schema. I think 1.2.3alpha1 works better. Dashes are not allowed in version.

[JohanMabille]

Would 1.2.3.alpha1 work? It would simplify the parsing.

[wolfv]

I think so, yes.

[Klaim]

Ok then, I'll do the necessary modifications for that scheme. 👍🏼

[jjerphan]

Thank you for opening a discussion.

Are .alpha* segments common? I think it is the case for the .dev ones, but alpha is generally concatenated to the patch number. That being said, I am not against it, and this proposal LGTM.

[Klaim]

Thank you for opening a discussion.

Are .alpha* segments common? I think it is the case for the .dev ones, but alpha is generally concatenated to the patch number. That being said, I am not against it, and this proposal LGTM.

Outside of mamba-related work, I'm mostly used to semantic-versioning-based version naming where - is used to separate the version name from the pre-release name, I've seen projects use -alphaN, -betaN , -dev1 etc. (and some package managers add dots, as semver allows it too).
I initially assumed semver was what conda package version scheme was following but Wolf clarified that it was not the case.
Other than that, all the packaging practice I have seen so far outside of conda's context (where I'm less familiar) will separate the pre-release name from the patch name for both clarity and helping tools to differentiate each the fields (a patch number is not a pre-release name, usually). That's why I personally tend to prefer to have a clear separator for the pre-release name (here . as - is already reserved in conda package versionning).

Is concatenating the pre-release name to the patch number is a common practice in the conda circles? Or was it just to workaround the lack of official pre-release field in the naming scheme?

[jjerphan]

Is concatenating the pre-release name to the patch number is a common practice in the conda circles?

This common in the python worlds given that PEP 440 specifies it, and it was then reused by conda packages.

[Klaim]

This common in the python worlds given that PEP 440 specifies it, and it was then reused by conda packages.

Thanks. At first glance, it seems that both this version and the up to date version, if I'm reading this correctly:

• specifies the pre-release name to be part of the minor section
• specifies aN for alpha (N is a number), bN for beta, rcN for release candidate
• specifies .devN (note the dot here) for development version (which can also be development versions of alphas/betas/etc. but not sure what that means exactly).
• separators for pre-release names are in fact accepted but should be interpreted without the separator (at normalization) if I understand this section correctly; but as said before - is explicitly forbidden in the case of conda packages, all the other rules applies.

Whatever we chose, does it have to strictly follow these rules? We already published 2.0.3alpha1 etc. which doesnt match these rules if my understanding is correct?
I'm fine with any version naming rules, just trying to figure out what we cannot and can do in the end.

edit> a section of my comment was not saved, fixed links

[jjerphan]

Whatever we chose, does it have to strictly follow these rules? We already published 2.0.3alpha1 etc. which doesnt match these rules if my understanding is correct?

Based on VERSION_PATTERN given in appendix B, this is correct.

I would suggest looking at this piece of conda.models.VersionOrder's docstring for an enumeration of cases.

[Klaim]

We had a meeting with @jjerphan @Hind-M and @JohanMabille and agreed that

• the scheme currently proposed v1.2.3.alpha4 is valid conda package version but will be normalized to 1.2.3a4 as per the specification and regex results (see canonical and packaging valid versions regexes)
• while there is no hard preference, there is a slight preference to have the . to separate the pre-release name
• therefore for now we continue with the proposed scheme

(I'll update the pr today with some tweaks)