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.a1
or1.1-a1
which 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.1
which would be normalized to1.0a1
.Pre-release spelling
Pre-releases allow the additional spellings of
alpha
,beta
,c
,pre
, andpreview
fora
,b
,rc
,rc
, andrc
respectively. This allows versions such as1.1alpha1
,1.1beta2
, or1.1c3
which 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 the0
explicitly. This allows versions such as1.2a
which 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
.