On Wed, Nov 25, 2009 at 9:04 PM, M.-A. Lemburg
Tarek Ziadé wrote:
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.
So perhaps this is just a misunderstanding on my part regarding the intended use of the new standard "rational" version format.
If the "rational" format is just used internally by distutils to compare resource versions, then why do we have to define the format in a PEP ?
If all external version strings (e.g. from the setup() call or PyPI) first go through suggest_rational_version(), then why not define its supported set of version strings in the PEP instead ?
I was under the impression that developers should be encouraged to use the new "rational" version format directly in their package versions - without a helper in between.
Yes that's the idea. I was just suggesting that "suggest_rational_version" could be used (maybe with a warning displayed) to avoid a brutal breakage in versions supports. I'll make it clearer in the PEP [..]
I'd still like to write "1.2beta3" and "2.1rc3", though, and be standards compliant :-)
I don't have any strong opposition into adding "rc", especially since Python uses it too. Now, for "alpha", "beta", I am not opposed at them either. I am just thinking that we should have only one way to name a pre-release tag, but I guess we can consider that "b" is an alias for "beta" So the pre-release tag would be one of those : a, alpha, b, beta, r, rc I don't think we need to support more letters though, e.g. [a-z] Regards Tarek