On Wed, Nov 25, 2009 at 9:04 PM, M.-A. Lemburg <m...@egenix.com> wrote: > Tarek Ziadé wrote: >> 2009/11/25 M.-A. Lemburg <m...@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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
