2009/11/25 M.-A. Lemburg
M.-A. Lemburg wrote:
Could we extend the pseudo-format of the versions a little to also include variants which use more than just one character and also allow hyphens and spaces to be used for additional clarity ?
VERSION_RE = re.compile(r''' ^ (?P<version>\d+\.\d+) # minimum 'N.N' (?P<extraversion>(?:\.\d+)*) # any number of extra '.N' segments (?: [- .]* (?P<prerel>[a-z]+) # 'a'=alpha, 'b'=beta, 'c'=release candidate [- .]* (?P<prerelversion>\d+(?:\.\d+)*) )? (?P<postdev> ([- .]*post[- .]*(?P<post>\d+))? ([- .]*dev[- .]*(?P<dev>\d+))? )? $''', re.VERBOSE + re.I)
The pre-release marker would then be interpreted in alphabetical order, ie. 'alpha' < 'beta' < 'rc'.
This minor change would broaden the scope of the scheme somewhat and make it more compatible to what's being used outside the python-dev sphere (esp. with respect to 'c' standing for release candidate... unless you happen to read it as gamma ;-).
... and even python-dev has switched to "rc" for these:
http://www.python.org/dev/peps/pep-0361/
The added optional hypens and spaces make the versions more readable, IMHO.
The goal of the scheme is to propose a unique standard, together with the "suggest_rational_version" API that allow transforming an almost-rational version to a rational version. IOW, having several ways of defining separators would make the version scheme loose. I have the feeling this would have a negative impact but I don't have a strong example in mind yet. Now, suggest_rational_version is meant to transform those close-enough versions strings into working strings, Example with "rc" vs "c":
from verlib import suggest_rational_version suggest_rational_version('2.4rc1') '2.4c1'
Meaning that a package manager could be permissive and use those almost-rational form with this API. So if we get suggest_rational_version work with hypens and spaces as you are suggesting, that could be a solution. Now, about the "c" choice. "c" was preferred to "rc" here to avoid using "r" which has a strong Subversion connotation. Next, hyphens were removed because they are avoided in some systems like Debian or Ubuntu, and have a very specific meaning in setuptools. from the setuptools doc: The algorithm assumes that strings like "-" and any alpha string that alphabetically follows "final" represents a "patch level". So, "2.4-1" is assumed to be a branch or patch of "2.4", and therefore "2.4.1" is considered newer than "2.4-1", which in turn is newer than "2.4". Regards Tarek