Similarities between GNOME and Python versioning

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-release separators

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 as 1.1.a1 or 1.1-a1 which would be normalized to 1.1a1. It should also allow a separator to be used between the pre-release signifier and the numeral. This allows versions such as 1.0a.1 which would be normalized to 1.0a1.

Pre-release spelling

Pre-releases allow the additional spellings of alpha, beta, c, pre, and preview for a, b, rc, rc, and rc respectively. This allows versions such as 1.1alpha1, 1.1beta2, or 1.1c3 which normalize to 1.1a1, 1.1b2, and 1.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 the 0 explicitly. This allows versions such as 1.2a which is normalized to 1.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.

1 Like