[Distutils] PEP 386 status - last round here ?

[Tarek Ziadé]

On Wed, Nov 25, 2009 at 9:04 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> Tarek Ziadé wrote:
>> 2009/11/25 M.-A. Lemburg <mal at egenix.com>:
>>> 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