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. IMHO, that intent would go a much longer way, since the user visible version strings would then follow this standard. However, since distutils only needs to be able to compare the versions, without actually knowing what 'alpha', 'beta' and 'rc' mean, I don't (currently) see a reason not to allow complete words in the version string.
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.
I don't believe that any developer who knows that revisions are marked as "r123" would mistake "rc" for a revision marker ;-)
Next, hyphens were removed because they are avoided in some systems like Debian or Ubuntu, and have a very specific meaning in setuptools.
That's a good point. RPM doesn't like hyphens in versions either... so forget the hyphen and spaces idea. I'd still like to write "1.2beta3" and "2.1rc3", though, and be standards compliant :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 25 2009)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/