[Distutils] PEP 386 status - last round here ?

[ssteinerX@gmail.com]

On Nov 25, 2009, at 12:44 PM, M.-A. Lemburg wrote:

> 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:

While I like the use of "rc" for release candidate, doesn't this lead to some ambiguity where a,b,c are seen as interim releases with "rc" sorting after all of these?

I don't have an objection to [a-q] OR 'rc' if we're reserving "rc" for release candidate and only "rc" for that purpose.

Otherwise, the sorting becomes ambiguous so if "c" means candidate then "rc" can't also or we don't know, for sure, that blah-rc comes AFTER blah-c; it's ambiguous.

S