It is very nearly the Python versioning scheme, though, and in fact it should be compatible with at least distutils.version.LooseVersion, and most likely distutils.version.StrictVersion as well. In particular, this issue raised by @fabiscafe:
Any such package management system would already have issues with Python version numbering, which uses the same basic patterns, and is documented to support the exact formatting chosen here (though it’s not the default/normalized form).
Since PEP 440:
Pre-releases should allow a
.,-, or_separator between the release segment and the pre-release segment. The normal form for this is without a separator. This allows versions such as1.1.a1or1.1-a1which would be normalized to1.1a1. It should also allow a separator to be used between the pre-release signifier and the numeral. This allows versions such as1.0a.1which would be normalized to1.0a1.Pre-release spelling
Pre-releases allow the additional spellings of
alpha,beta,c,pre, andpreviewfora,b,rc,rc, andrcrespectively. This allows versions such as1.1alpha1,1.1beta2, or1.1c3which normalize to1.1a1,1.1b2, and1.1rc3. In every case the additional spelling should be considered equivalent to their normal forms.Implicit pre-release number
Pre releases allow omitting the numeral in which case it is implicitly assumed to be
0. The normal form for this is to include the0explicitly. This allows versions such as1.2awhich is normalized to1.2a0.
This makes e.g. 40.alpha a completely valid alternate form, which would normalize to 40a0. And Python already uses post-release bumps, i.e. Python 3.9a1 is lower than Python 3.9b0 is lower than Python 3.9rc2, and all are lower than either Python 3.9 or Python 3.9.0.