Hi Tarek, Tarek Ziadé wrote:

Anyone see any problem ? or have any concern with this PEP ?

Just a question: will it affect how version are checked for tools (e.g. get_versions in distutils/cygwinccompiler.py) ? cheers, David

Tarek Ziadé wrote:

This behavior will not be affected.

Ok.

Although, I havn't looked at gcc, ld and dllwrap version schemes yet.

If they are compatible with RationalVersion these functions will use it.

If not, I will probably keep something similar to LooseVersion, but dedicated to this usage. So maybe renamed accordingly so they are specific to gcc/ld/dllwrap schemes

In that case, maybe LooseVersion could be redefined to something which does not do anything for cygwin case. The current behavior often breaks cygwin builds because LooseVersion is not capable of parsing upstream versions, and I don't really understand the rationale for checking the version in the first place. thanks, David

On Tue, Nov 24, 2009 at 2:31 PM, ssteinerX@gmail.com wrote: [..]

There are, however, some issues that should be addressed before it's accepted as "final."

1>      There seems to be a typo on line 29 of verlib.py where it says 'f' < 'b', shouldn't that be 'b' < 'f' ?

Right, fixed. thanks !

2>      The explanation for "suggest_rational_version" is stubbed out in the README.txt file:

               XXX explain here suggest_rational_version

       it should be documented what we expect it to do and that leads into...

This README.txt is a bit outdated. It's an old copy of PEP 386 (which explains suggest_rational_version)

3>      test_suggest_rational_version needs a more comprehensive test suite (like all the version numbers from PyPi).  Right now it only has 11 cases and they're all pretty mild though the doc asserts success rates on PyPi that are much higher.  This should be done so that we can insure that the algorithm stays stable (and hopefully improves) in future versions.  (I will create this expanded test using PyPi data, if requested).

That would be great,

4>      The [#requrires] reference is missing from the README.txt file

I'll update it using the latest PEP 376 text

5>      There is no cross reference to any other non-python project using this scheme.  There is a note that  "During Pycon, members of the Python, Ubuntu and Fedora community worked on a version standard that would be acceptable for everyone"  but there is no evidence that anyone else has agreed to this standard and, particularly, to this reference implementation.

I don't think any project uses this scheme yet, besides some Python projects. What happened is that when we worked on this scheme, Toshio (Fedora) and Matthias (Ubuntu/Debian) made sure it would be acceptable for their needs to translate it in their own schemes automatically. For instance, RPMs want to avoid date-based versions, and Debian packages avoids "-" characters. Tarek

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 ;-). The added optional hypens and spaces make the versions more readable, IMHO. -- 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/

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. 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. Next, hyphens were removed because they are avoided in some systems like Debian or Ubuntu, and have a very specific meaning in setuptools. from the setuptools doc: The algorithm assumes that strings like "-" and any alpha string that alphabetically follows "final" represents a "patch level". So, "2.4-1" is assumed to be a branch or patch of "2.4", and therefore "2.4.1" is considered newer than "2.4-1", which in turn is newer than "2.4". Regards Tarek

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/

On Wed, Nov 25, 2009 at 9:04 PM, M.-A. Lemburg wrote:

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

On Wed, Nov 25, 2009 at 9:52 PM, M.-A. Lemburg wrote: [..]

If we'd allow [a-z_] (including the underscore which AFAIK doesn't cause RPM/deb problems), this could also be written as:

       3.2.0_dev_snapshot.20091125

... much better :-)

How do you sort them in that case ? And can you have snapshots of pre-release tags ? e.g., is this right ? : 3.2.0_dev_snapshot.20091125 < 3.2.0a_dev_snapshot.20091125 < 3.2.0rc1_dev_snapshot.20091125 < 3.2.0

Tarek Ziadé wrote:

On Wed, Nov 25, 2009 at 9:52 PM, M.-A. Lemburg wrote: [..]

...

If we'd allow [a-z_] (including the underscore which AFAIK doesn't cause RPM/deb problems), this could also be written as:

3.2.0_dev_snapshot.20091125

... much better :-)

How do you sort them in that case ? And can you have snapshots of pre-release tags ?

You sort them based on the tag "_dev_snapshot". The leading underscore causes the tag to sort before the first release tag (which would start with a letter, like in "alpha"):

...

...

"_dev_snapshot" < "alpha" True

e.g., is this right ? :

3.2.0_dev_snapshot.20091125 < 3.2.0a_dev_snapshot.20091125 < 3.2.0rc1_dev_snapshot.20091125 < 3.2.0

Yes (*), even though, I'd probably drop the "_dev_snapshot" on these and write: 3.2.0_dev_snapshot.20091125 < 3.2.0a1 < 3.2.0a1.20091125 < 3.2.0rc1 < 3.2.0rc1.20091125 < 3.2.0 It's clear from the added version component that the version points to revision after the release revision. With the PEP format, I could write: 3.2.0a1.dev20091125 < 3.2.0a1 < 3.2.0a1.post20091125 < 3.2.0rc1 < 3.2.0rc1.post20091125 < 3.2.0 ... but I doubt that users would understand the difference between "dev" and "post". Furthermore, the "dev" and "post" modifiers don't follow the same semantics as the pre-release tags. This version would use the same semantics for both, but looks even worse: 3.2.0a1.0a20091125 < 3.2.0a1 < 3.2.0a1.0a20091125 < 3.2.0rc1 < 3.2.0rc1.0a20091125 < 3.2.0 I'd just drop the whole post/dev stuff and allow additional (\.\d+) components after the pre-release tag part. One pre-release field per version string is really enough, IMHO. An alternative based on the same convention we use for Python would be to use the "alpha 0" release as marker for pre-release snapshots. The a0 "release" is then never actually released. Using this convention, I could write: 3.2.0a0.20091125 < 3.2.0a1 < 3.2.0a1.20091125 < 3.2.0rc1 < 3.2.0rc1.20091125 < 3.2.0 ... looks good :-) (*) with one nit: the third one needs to be 3.2.0rc_dev_snapshot_1.20091125 since the "1" in "rc1_dev_snapshot" is not allowed. -- 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/

On Thu, Nov 26, 2009 at 1:08 PM, M.-A. Lemburg wrote:

Here's another take at a minimal change to the format which includes the things we discussed, adds a few more aliases for the "post" and "dev" markers and also adds optional underscores for more readability.

VERSION_RE = re.compile(r'''    ^    (?P<version>\d+\.\d+)          # minimum 'N.N'    (?P<extraversion>(?:\.\d+)*)   # any number of extra '.N' segments    (?:                            # pre-release tag        _?        (?P<prerel>(a|alpha|b|beta|c|rc))        _?        (?P<prerelversion>\d+(?:\.\d+)*)    )?    (?P<postdev>        (\.(post|fix|sp)_?(?P<post>\d+))?        (\.(dev|pre|build|nightly)_?(?P<dev>\d+))?    )?    $''', re.VERBOSE + re.I)

Examples:

 3.2.0a0.20091125 < 3.2.0a1 = 3.2.0_alpha_1 < 3.2.0a1.20091125 < 3.2.0rc1 = 3.2.0c1 < 3.2.0rc1.20091125 = 3.2.0_rc1.20091125 < 3.2.0 < 3.2.0.sp1 = 3.2.0.fix1 = 3.2.0.post1

One nit I have with the order of the N.N.devN version is that it is regarded "more" than any of the pre-release tags, but less than the release itself:

 1.0a1 < 1.0rc1 < 1.0.dev456 < 1.0

IMHO, the order should be:

 1.0.dev456 < 1.0a1.dev456 < 1.0a1 < 1.0rc1.dev456 < 1.0rc1 < 1.0

since the .dev versions are really only snapshots leading up to some release, i.e. 1.0.dev456 is a snapshot leading up to the first pre-release of the 1.0 :-)

That's right, that's a bug in the PEP and/or verlib.py The changes look good to me. If you made some changes in verlib, would you mind pushing them back at http://bitbucket.org/tarek/distutilsversion ? I'll update the PEP then, and if there's no more feedback here, I'll propose it at python-dev Regards Tarek

On Thu, Nov 26, 2009 at 8:55 PM, Floris Bruynooghe wrote: [..]

...

since the .dev versions are really only snapshots leading up to some release, i.e. 1.0.dev456 is a snapshot leading up to the first pre-release of the 1.0 :-)

But in this case if I want to make a pre-release of 1.0 but after the last rc then I can't, I can only make a post-release of the last rc. That's almost more un-intuitive that forcing your first pre-release to be '1.0a0.dev456' instead of just '1.0.dev456'.

It seems to me that the number of development versions of rc releases is very low compared to the number of development snapshots done for 1.0, before the pre-release cycle starts. (I don't think I have ever needed a dev snapshot of a rc version) I am +1 for keeping the intuitive writing for the pre-release cycle. e.g. 1.0.dev456 < 1.0a1.dev456 < 1.0a1 < 1.0rc1.dev456 < 1.0rc1 < 1.0rc1.post123 < 1.0 Regards, Tarek

At 07:55 PM 11/26/2009 +0000, Floris Bruynooghe wrote:

On Thu, Nov 26, 2009 at 01:08:34PM +0100, M.-A. Lemburg wrote:

...

Examples:

3.2.0a0.20091125 < 3.2.0a1 = 3.2.0_alpha_1

Frankly I find this confusing. I'm fine with 'alpha' being a synonym for 'a' but the underscores just confuse things IMHO.

They're also not backwards-compatible with the current schemes being used by setuptools and its derivatives (Distribute, pip, buildout, etc.), which interprets underscores differently. (Technically, an underscore should never be in a version, since underscores are used in filenames as an escaped version of a dash.)

On Fri, Nov 27, 2009 at 11:39 AM, Piotr Ozarowski wrote:

[Tarek Ziadé, 2009-11-26]

...

On Thu, Nov 26, 2009 at 8:55 PM, Floris Bruynooghe wrote: [..]

...

...

since the .dev versions are really only snapshots leading up to some release, i.e. 1.0.dev456 is a snapshot leading up to the first pre-release of the 1.0 :-)

But in this case if I want to make a pre-release of 1.0 but after the last rc then I can't, I can only make a post-release of the last rc. That's almost more un-intuitive that forcing your first pre-release to be '1.0a0.dev456' instead of just '1.0.dev456'.

It seems to me that the number of development versions of rc releases is very low compared to the number of development snapshots done for 1.0, before the pre-release cycle starts.

(I don't think I have ever needed a dev snapshot of a rc version)

I am +1 for keeping the intuitive writing for the pre-release cycle.

e.g.

 1.0.dev456  < 1.0a1.dev456  < 1.0a1  < 1.0rc1.dev456  < 1.0rc1  < 1.0rc1.post123  < 1.0

why not simply use "-" and "+" where "-" is before zero-length string and "+" is after any other string... and then sort the rest alphabetically? f.e.

 1.0-a1-dev456 < 1.0-a1 < 1.0-a1+dev456 < 1.0-dev456 < 1.0-rc1-dev456 < 1.0-rc1 < 1.0-rc1+post123 < 1.0 < 1.0+post123

don't worry about Debian, we'll simply replace "-" with "~" (we use "~" and "+" right now[0]). I'm not sure about rpm, but I bet it has something similar and it will be much easier for us to simply handle two characters instead of recognizing that dev1 < a1 < b1 < c1 == rc1 ...

From rmp5.org: """ The algorithm that RPM uses to determine the version ordering of

It's different from RPMs, since they use a strcmp(), segment by segment, so I think they have to extract the dev/post suffixes and to put them in front as an epoch marker maybe ? (ccing Toshio) Meaning that they would need to split on "-", and replace "+" by "z", and use the segments in reverse order before comparing the first Major.Minor.Micro part, # rmpdev-vercmp "1.0-a1-dev456" "1.0" 0:1.0-a1-dev456 is newer # rmpdev-vercmp "1.0~a1" "1.0-a1" 0:1.0~a1-None is newer # rmpdev-vercmp "1.0-a1-2" "1.0-a1~2" These are equals packages is simple and developers are encouraged not to rely on the details of its working. Developers should keep their numbering scheme simple so any reasonable ordering algorithm would work. The version comparison algorithm is in the routine rpmvercmp() and it is just a segmented strcmp(3). First, the boundaries of the segments are found using isdigit(3)/isalpha(3). Each segment is then compared in order with the right most segment being the least significant. The alphabetical portions are compared using a lexical graphical ascii ordering, the digit segments strip leading zeroes and compare the strlen before doing a strcmp. If both numerical strings are equal, the longer string is larger. Notice that the algorithm has no knowledge of decimal fractions, and perl-5.6 is "older" than perl-5.00503 because the number 6 is less than the number 503. """ Tarek

Tarek Ziadé writes:

That makes me think that a nice add-on to the lib and the PEP would be to provide APIs to translate a Python PEP 386 version to a Debian/Ubuntu or RPM ones - and any major packaging system out there. (whatever scheme we pick)

I'd like to register, once again, the point that this would not *be* a problem if PEP 386 described a version comparison scheme that simply works without special keywords. Have each segment compared alphanumerically, and it will not *need* translation to work with other packaging systems. Special keywords are not, I maintain, special enough to break the normal version-comparison semantics. -- \ “I would rather be exposed to the inconveniences attending too | `\ much liberty than those attending too small a degree of it.” | _o__) —Thomas Jefferson | Ben Finney

On Fri, Nov 27, 2009 at 1:52 PM, Ben Finney wrote:

Tarek Ziadé writes:

...

That makes me think that a nice add-on to the lib and the PEP would be to provide APIs to translate a Python PEP 386 version to a Debian/Ubuntu or RPM ones - and any major packaging system out there. (whatever scheme we pick)

I'd like to register, once again, the point that this would not *be* a problem if PEP 386 described a version comparison scheme that simply works without special keywords. Have each segment compared alphanumerically, and it will not *need* translation to work with other packaging systems.

Special keywords are not, I maintain, special enough to break the normal version-comparison semantics.

Not sure what you mean by special keywords. If it's about 'post' and 'dev', the problem we have is to be able to sort those post and pre releases with other versions. And this is not possible with a simple alphanumerical comparison. And this is not a special use case, and has to be part imho of our version-comparison semantics. otherwise, our scheme would be useless for developers that work as a daily basis with snapshots, dev versions etc. Tarek

On Fri, Nov 27, 2009 at 3:31 PM, ssteinerX@gmail.com wrote:

On Nov 27, 2009, at 7:31 AM, Tarek Ziadé wrote:

...

On Fri, Nov 27, 2009 at 1:24 PM, Tarek Ziadé wrote: [..]

...

...

don't worry about Debian, we'll simply replace "-" with "~" (we use "~" and "+" right now[0]). I'm not sure about rpm, but I bet it has something similar and it will be much easier for us to simply handle two characters instead of recognizing that dev1 < a1 < b1 < c1 == rc1 ...

It's different from RPMs, since they use a strcmp(), segment  by segment, so I think they have to extract the dev/post suffixes and to put them in front as an epoch marker maybe ? (ccing Toshio)

That makes me think that a nice add-on to the lib and the PEP would be to provide APIs to translate a Python PEP 386 version to a Debian/Ubuntu or RPM ones - and any major packaging system out there. (whatever scheme we pick)

Wouldn't it be cool if the package that goes along with this PEP became the standard version checker used by ALL of these distributions?

It's not like they don't have Python interpreters around...

Piotr makes the point that every packaging system has already its recipes and own tools, that are not Python-based for some of them. But it doesn't hurt to provide something on our side too it I think.

What would that API have to look like?  Maybe start a doc in the repo to hold that spec as we develop it?

The PEP 386 verlib API is ending in Distutils anyways, so third party package managers will be able to use verlib in their tools if they want. So once the version scheme is decided, we can talk about extending the lib to add more functions besides "suggest_rational_version". The question will be to decide if it's stable enough to have it Distutils. But that won't be a PEP discussion anymore, e.g. just candy on the top of the version scheme.

I'm still very interested in the increment_version functionality we talked about earlier so that we could have our build process automatically up our release version numbers so we have a standard way of maintaining incremental versioning.

That would be an interesting feature Tarek

On Nov 27, 2009, at 9:41 AM, Tarek Ziadé wrote:

...

I'm still very interested in the increment_version functionality we talked about earlier so that we could have our build process automatically up our release version numbers so we have a standard way of maintaining incremental versioning.

That would be an interesting feature

I think I'll start it a separate project, calling into the API, that can just be put into any build process. If it works well enough stand-alone, maybe we'll incorporate it later. S

Many many things in this thread.... Unfortunately, there's so many ways to do versioning that it's almost a bikeshed topic and so there's a lot of different ideas of what could be right. Let me start by saying what I think is "right" and then the rest of my message will be devoted to what things seem like good compromises and what don't :-) I'm in agreement with Ben Finney's idea:: """ I'd like to register, once again, the point that this would not *be* a problem if PEP 386 described a version comparison scheme that simply works without special keywords. Have each segment compared alphanumerically, and it will not *need* translation to work with other packaging systems. Special keywords are not, I maintain, special enough to break the normal version-comparison semantics. """ However, at PyCon, this was only popular among the people who have to deal with packaging of python projects. Everyone else wants the ability to sort some things as coming before a release -- for instance, alphas, betas, release candidates. (Note that snapshots don't need to be pre-releases although this PEP makes them that way). On Fri, Nov 27, 2009 at 01:24:14PM +0100, Tarek Ziadé wrote:

On Fri, Nov 27, 2009 at 11:39 AM, Piotr Ozarowski wrote:

...

[Tarek Ziadé, 2009-11-26]

...

On Thu, Nov 26, 2009 at 8:55 PM, Floris Bruynooghe wrote: [..]

...

...

since the .dev versions are really only snapshots leading up to some release, i.e. 1.0.dev456 is a snapshot leading up to the first pre-release of the 1.0 :-)

But in this case if I want to make a pre-release of 1.0 but after the last rc then I can't, I can only make a post-release of the last rc. That's almost more un-intuitive that forcing your first pre-release to be '1.0a0.dev456' instead of just '1.0.dev456'.

It seems to me that the number of development versions of rc releases is very low compared to the number of development snapshots done for 1.0, before the pre-release cycle starts.

(I don't think I have ever needed a dev snapshot of a rc version)

I am +1 for keeping the intuitive writing for the pre-release cycle.

e.g.

 1.0.dev456  < 1.0a1.dev456  < 1.0a1  < 1.0rc1.dev456  < 1.0rc1  < 1.0rc1.post123  < 1.0

Note, what I "intuitivly" see from the given version numbers is more like this:: 0.9 < 0.9.dev456 < 1.0rc1 < 1.0rc1.dev456 < 1.0rc1.post123 < 1.0 < 1.0.dev456 < 1.0a1 < 1.0a1.dev456 I've been trained by many projects to see "rc" as "release candidate" but the definition of "a" and "b" differs from project to project. Many projects use them as "patchlevels" for minor post-releases instead of abbreviations for alpha and beta. Also, if you have a directory of revisions being served up by apache it's going to put them in strcmp() order, so 1.0 is going to sort after the rc's, the .dev's, and the a1's. Much confusion to overcome here. Is this a bikeshed? In some ways it is because some people will "intuitively" see prereleases and others will see postreleases. However, versioning impacts end users so we should strive to make it as easy as possible for people to see the real meaning of our versions. At pycon I suggested that everything should be treated as a postrelease except for certain specific words like "alpha", "beta", and "rc" and that we should strive to keep that list of specific words as small as possible to avoid confusion. This might be a good place to say that I agree with part of what Marc-Andre Lemburg says: """ 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 ;-). """ Like Marc-Andre I think alpha, beta, rc contain the information to remove confusion while "a", "b", and "c" do not. However, I do not like having aliases (ie: "a"== "alpha"). Aliases have several problems: 1) How do you sort: 1.0a1 and 1.0alpha1 ? Using an alias these are the same release but since the developer of the package did this intentionally, they obviously meant them to mean something different... we just don't know what that something is. 2) Eventually, someone will think that "a", "b", and "c" are for patchlevels. Then we'll have someone releasing code that they expect to work like this:: 1.0-alpha1 1.0 1.0-a1 The version checking code will okay it since each one is correct by itself. It's the meaning that the author attributes to them that will be wrong. Floris Bruynooghe points these issues out although he uses "dev" and "post" which have distinct meanings in the PEP: """ I also object to the alternatives for the 'dev' and 'post' markers as they make it more confusing for me. While someone might prefer one word over the other their meaning does not change to decide their ordering, that just seems like uneeded complexity (there should be only one obvious way to do a thing?). When I now see the versioning number of a project I need to go and look up the pep to know if it's compliant but just using one of the alternatives that I'm not used to. If there's only one choice it's a lot easier. (This same argument goes for 'a' == 'alpha' 'b' == 'beta' and 'c' == 'rc' but those at least are mnemonic so easier to remember) """ By pointing these out, I don't want to stop progress since other people seem very attached to using "a", "b", "c" instead of fully spelled out alpha, beta and rc but I defintely see that as a wart. (Emphasis on "instead of", not in addition to.)

...

why not simply use "-" and "+" where "-" is before zero-length string and "+" is after any other string... and then sort the rest alphabetically? f.e.

 1.0-a1-dev456 < 1.0-a1 < 1.0-a1+dev456 < 1.0-dev456 < 1.0-rc1-dev456 < 1.0-rc1 < 1.0-rc1+post123 < 1.0 < 1.0+post123

don't worry about Debian, we'll simply replace "-" with "~" (we use "~" and "+" right now[0]). I'm not sure about rpm, but I bet it has something similar and it will be much easier for us to simply handle two characters instead of recognizing that dev1 < a1 < b1 < c1 == rc1 ...

It's different from RPMs, since they use a strcmp(), segment by segment, so I think they have to extract the dev/post suffixes and to put them in front as an epoch marker maybe ? (ccing Toshio)

There's a few things to think about here. First, there's the underlying tool. In Debian, that's dpkg and in Fedora, it's rpm (Note: www.rpm.org, not www.rpm5.org, the latter is a fork.) The tool enforces things like "-" is a separator between fields, "." as a separator inside fields, and ordering of packages based on what's contained in the fields. In rpm we have this to work with:: :Name: Name of a package. This makes "python" different from "python-docs" different from "gcc" :Epoch: This is the trump card of the version sorting. We seldom use this as it doesn't show up in our filenames or other end-user visible interfaces. It is used for correcting mistakes in versioning or times when we decide that we absolutely have to revert a package rather than continuing to package the current release. :Version: This is generally the upstream release. However, upstream will frequently make releases that won't order correctly (for instance, 1.0alpha1 => 1.0; strcmp() will order these as 1.0 => 1.0alpha1) All distributions have to transform the version in some way to make ordering work correctly with the upstream's versions but they have different methods. Additionally, we want the upstream version to be apparent from the version and release fields since end users will see these two fields in the filenames of the packages and we want them to know they're getting, for instance, the upstream 2.6.1 release of python. :Release: The release of the package within the distribution. If upstream version ordering exactly fit the rpm algorithm, this would just be an integer that incremented everytime we built the same upstream version of the package. It's the least significant of the fields on ordering. Each distribution has its own rules for dealing with the upstream version so that rpm will order things correctly. In Fedora, they involve taking the initial version string that consists of [0-9.] and leaving that in version. Anything beyond that initial portion is put into the release after our portion of the release. For instance if upstream makes the following releases: Upstream Version Release -------- ------- ------- libjpeg-2.0alpha1 2.0 0.1.alpha1 libjpeg-2.0 2.0 1 libjpeg-2.0a 2.0 2.a Gory details: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Version (Version and Release section) Here's how we would map each of the examples in Fedora. Note that at the moment this is a manual process as we can't depend on upstreams to only follow this. I'll separate our version and release with a "-" as that's how rpm will show it to our users: 1.0.dev456 1.0-0.1.dev456 < 1.0a1.dev456 1.0-0.2.a1.dev456 < 1.0a1 1.0-0.3.a1 < 1.0rc1.dev456 1.0-0.4.rc1.dev456 < 1.0rc1 1.0-0.5.rc1 < 1.0rc1.post123 1.0-0.6.rc1.post123 < 1.0 1.0-1 ============ 1.0-a1-dev456 1.0-0.1.a1.dev456 < 1.0-a1 1.0-0.2.a1 < 1.0-a1+dev456 1.0-0.3.a1+dev456 < 1.0-dev456 1.0-0.4.dev456 < 1.0-rc1-dev456 1.0-0.5.rc1.dev456 < 1.0-rc1 1.0-0.6.rc1 < 1.0-rc1+post123 1.0-0.7.rc1+post123 < 1.0 1.0-1 < 1.0+post123 1.0-2.post123 We can work with whatever is given to us... just the number of hoops and special cases that we have to remeber what the position is when we do so. That said, I don't see the reason for this change. 1) current post is similar to (+post and +dev) current dev is similar to (-post and -dev) Why duplicate functionality that's already in the PEP? 2) If we remove the "post" version string, then you are substituting a nice, spelled out word ("post") with a cryptic symbol ('+'). 3) The position of the -dev456 in your list satisfies neither set of people who want to define the meaning of dev. It's showing up between a1 and rc1 whereas one camp wants it to sort before a1 and the other camp wants it to sort just before 1.0. ?) Where does 1.0-post123 fall in your list? -Toshio

Ben Finney wrote:

Yes, and others that have been proposed to be exceptions to alphanumeric ordering.

...

the problem we have is to be able to sort those post and pre releases with other versions. And this is not possible with a simple alphanumerical comparison.

It is, if the version strings are chosen to fit within such a comparison semantic.

...

And this is not a special use case, and has to be part imho of our version-comparison semantics. otherwise, our scheme would be useless for developers that work as a daily basis with snapshots, dev versions etc.

This is a red herring, AFAICT. It's been discussed already that workflow is orthogonal to version comparison semantics. That is, nothing about a workflow involving snapshots or dev versions etc. implies that exceptional version keywords need to be accommodated. Exactly the same workflow can take place by choosing different version strings that work with existing version-comparison semantics.

How would you propose Python itself (a project that doesn't have especially wacky release numbers) specify 3.1.1rc1 in such a scheme?

At 10:32 AM 11/28/2009 +1100, Ben Finney wrote:

This is a red herring, AFAICT. It's been discussed already that workflow is orthogonal to version comparison semantics. That is, nothing about a workflow involving snapshots or dev versions etc. implies that exceptional version keywords need to be accommodated. Exactly the same workflow can take place by choosing different version strings that work with existing version-comparison semantics. Moreover, AIUI there is no injunction that all projects must follow exactly the semantics of PEP 386, right? So why not have a *simple* standard (all version string components compared alphanumerically) in PEP 386, that is known to work unmodified with existing package systems, without Python-specific translation layers for version comparison?

For the simple reason that it involves asking one group of people to change how they work -- with no immediate benefit -- so that another group can avoid having to change how they work. Why should developers change, and packagers not? It's simply not an equitable request, which is why the proposal is unrealistic.

Ben Finney wrote:

Eric Smith writes:

...

Ben Finney wrote:

...

...

the problem we have is to be able to sort those post and pre releases with other versions. And this is not possible with a simple alphanumerical comparison. It is, if the version strings are chosen to fit within such a comparison semantic. […]

...

How would you propose Python itself (a project that doesn't have especially wacky release numbers) specify 3.1.1rc1 in such a scheme?

Since the specification is about version *comparison* semantics, I'd need to know example version strings that should compare “prior” and “subsequent” for the version string I'm to propose. Can you give examples?

I want to install the latest version of Python. My choices are 3.3.1 (the released version) and 3.3.1rc1.

Eric Smith writes:

Ben Finney wrote:

...

Since the specification is about version *comparison* semantics, I'd need to know example version strings that should compare “prior” and “subsequent” for the version string I'm to propose. Can you give examples?

I want to install the latest version of Python. My choices are 3.3.1 (the released version) and 3.3.1rc1.

And what version string should this compare prior to? That is, you want me to propose an example version string X. I'm asking for you to tell me corresponding examples of version strings W and Y where: W < X < Y since the comparison semantics are what we're discussing here. -- \ “There will be a Moscow Exhibition of the Arts by 15,000 Soviet | `\ Republic painters and sculptors. These were executed over the | _o__) past two years.” —newspaper article, Soviet Weekly | Ben Finney

On Sat, Nov 28, 2009 at 12:32 AM, Ben Finney wrote: [..]

...

the problem we have is to be able to sort those post and pre releases with other versions. And this is not possible with a simple alphanumerical comparison.

It is, if the version strings are chosen to fit within such a comparison semantic.

So how do you sort development version and post-release versions in a "simple" alphanumeric order ?

...

And this is not a special use case, and has to be part imho of our version-comparison semantics. otherwise, our scheme would be useless for developers that work as a daily basis with snapshots, dev versions etc.

This is a red herring, AFAICT. It's been discussed already that workflow is orthogonal to version comparison semantics. That is, nothing about a workflow involving snapshots or dev versions etc. implies that exceptional version keywords need to be accommodated. Exactly the same workflow can take place by choosing different version strings that work with existing version-comparison semantics.

I don't understand what you mean by workflow. When you need to compare versions, wether they are development versions, or pre and post-release versions, or final version, you need to sort them.

Moreover, AIUI there is no injunction that all projects must follow exactly the semantics of PEP 386, right? So why not have a *simple* standard (all version string components compared alphanumerically) in PEP 386, that is known to work unmodified with existing package systems, without Python-specific translation layers for version comparison?

A project process is not a private thing. If you use third party libraries, you hit the problem of having to install development versions or pre-release versions. Tarek.

On Sat, Nov 28, 2009 at 2:26 AM, Ben Finney wrote: [..]

...

Why should developers change, and packagers not?

Packagers *do* change how they work; Piotr has been explaining at length how packagers put in efforts to meet version-comparison semantics half way. I'm asking that the standardisation effort at least not make this effort more difficult that it needs to be.

Piotr, and all os packagers will always have to transform our versions into theirs. Once we have chosen it, it will not make their life more difficult. It's just one regular expression doing the work. Its size may vary that's all. Moreover, they will be able to do a better work because they will stop guessing the versions of Python packages, they will just stick with a *documented* standard.

Moreover, what is a standard for if not for encouraging people to follow it for the benefit of many?

...

It's simply not an equitable request, which is why the proposal is unrealistic.

I think you're reading a proposal that I didn't write.

It's a realistic standard. It's an equitable request. You can do whatever you want to do with your versions internally. But as soon as you publish them, they HAVE to be ordered by other tools that deal with your package, like installers. So you have two choices: - an implicit, heuristic ordering (that's what is happening today) - a explicit, documented ordering. that's the goal of PEP 386. I don't see why this is not a benefit for all of us. Tarek

Ben Finney wrote:

Eric Smith writes:

...

Ben Finney wrote:

...

Since the specification is about version *comparison* semantics, I'd need to know example version strings that should compare “prior” and “subsequent” for the version string I'm to propose. Can you give examples? I want to install the latest version of Python. My choices are 3.3.1 (the released version) and 3.3.1rc1.

And what version string should this compare prior to?

That is, you want me to propose an example version string X. I'm asking for you to tell me corresponding examples of version strings W and Y where:

W < X < Y

since the comparison semantics are what we're discussing here.

W = 3.3.0 Y = 3.3.1 If you're going to suggest 3.3.0.99 or some such, I think that won't work. It's important that code sees that as 3.3.1.<something>. I've seen code that fails when the pre-release versions have a different MAJOR.MINOR.MICRO than the final version. I really think we need a "subtractive" versioning scheme. Eric.

Eric Smith writes:

Ben Finney wrote:

...

That is, you want me to propose an example version string X. I'm asking for you to tell me corresponding examples of version strings W and Y where:

W < X < Y

since the comparison semantics are what we're discussing here.

W = 3.3.0 Y = 3.3.1

If you're going to suggest 3.3.0.99 or some such

Yes. Or any version string that would obviously fall between the two.

I think that won't work. It's important that code sees that as 3.3.1.<something>. I've seen code that fails when the pre-release versions have a different MAJOR.MINOR.MICRO than the final version.

It's exactly that kind of code that I don't feel needs to be accommodated. It's clearly causing ambiguities and contortions, and now we talk about needing Python-specific version comparison algorithms in order to automate the comparison. Why is this worth the trouble, when the standard could simply describe obvious-to-everyone version comparison semantics that are far easier for everyone to get right? -- \ “Visitors are expected to complain at the office between the | `\ hours of 9 and 11 a.m. daily.” —hotel, Athens | _o__) | Ben Finney

On Sat, Nov 28, 2009 at 12:28 PM, Floris Bruynooghe wrote:

On Fri, Nov 27, 2009 at 10:00:22PM -0500, P.J. Eby wrote:

...

This is why I've argued for keeping a scheme in 386 that can mechanically translate most existing versioning schemes found in the wild: it means that most people won't have to do a thing, as tool builders can just use suggest_version().

This is an important point.  I tought the aim of PEP 386 was to create a version scheme that can represent every version number developers want to express, not to create one that allows everyones favourite syntax.

Absolutely, "suggest_rational_version" is just here to allow package managers softwares to handle existing versions, and eventually raise a warning when they get those.

And it seems most of the discussion has now ventured back into the syntax (flamewars/bikeshedding?) instead of whether everyone can express the versions they need to.

Agreed. We jumped again in the black hole :) I don't see much progress in the thread. Fact 0: This PEP is important for interoperability Fact 1: We do need to express development versions, post/pre release versions and we do want to have a standard to be shared among public python package installers. Fact 2: there are many ways to express those markers, but the PEP will document *one* way and promote its usage, so public package installers are all *compatible* (distutils, pip, etc..) Fact3: suggest_rational_ version will offer a tool for installers to deal with more version schemes, and it is suggested that it warns the developer that the scheme is not PEP 386 compliant. So If the current proposal works for all cases (e.g. people can translate their schemes into PEP 386 one), I am proposing to: 1- reject the "+", " ", "-" proposal, and stick with "." so we have only one way to express the segments. (ala Python itself) 2 - keep the aliases (alpha/beta/rc) because they are not controversial 3 - stick with "post" "dev" for the post and pre-release tags because *we need them to sort development versions and post versions* in installers, and because *they don't hurt* for people that are not publishing such versions. They will be able to use their own dev markers internally if they want. Next, once the PEP is edited, I am proposing to move this discussion in python-dev, for another round, and eventually have Guido accept it or reject it and move forward with PEP 345. Because as far as I am concerned, even if we change the syntax in PEP 386 a million times, some people will not like it at the end. regards Tarek

On Sat, Nov 28, 2009 at 04:27:04PM +0100, Tarek Ziadé wrote:

On Fri, Nov 27, 2009 at 8:55 PM, Toshio Kuratomi wrote: [lots of explanation]

Thanks for these explanations Toshio. I am starting to think that whatever we use on Python side will be fine for you guys, (and for Ubuntu/Fedora guys), as long as it is described in the PEP.

Pretty much.

So I think that using '.' as we stated before "works" for everyone,

Now about the usage of "a1" as alpha for us, and a post release patch for you, this is something that won't be changed because it's deeply used in the Python community, (by Python itself, and most framworks) so we need to keep a status quo.

<nod> -- The only caveat to that is that aliases are a bad idea. So please don't add "alpha" as an alias for "a". If you must, add "alpha" and "a" separately so there is a predictable sorting between "alpha1" and "a1"... although this is still a way to make confusion rather than eliminate it. -Toshio

On Sat, Nov 28, 2009 at 05:07:01PM +0100, Tarek Ziadé wrote:

On Sat, Nov 28, 2009 at 12:28 PM, Floris Bruynooghe wrote:

...

This is an important point.  I tought the aim of PEP 386 was to create a version scheme that can represent every version number developers want to express, not to create one that allows everyones favourite syntax.

Absolutely,

Maybe worth explaining this in the abstract of the motivation of the PEP to focus discussion? Otherwise I reckon chances are pretty high that the syntax flameware will flare up again when this gets proposed on python-dev (or here if there's need for another round).

So If the current proposal works for all cases (e.g. people can translate their schemes into PEP 386 one), I am proposing to: [...]

+1, I think that's a good approach (+0 on the aliases part though) Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org

At 08:11 PM 11/28/2009 +0100, M.-A. Lemburg wrote:

Tarek Ziadé wrote:

...

On Thu, Nov 26, 2009 at 1:08 PM, M.-A. Lemburg wrote:

...

Here's another take at a minimal change to the format which includes the things we discussed, adds a few more aliases for the "post" and "dev" markers and also adds optional underscores for more readability.

Please don't add underscores to the syntax -- they will cause problems with the filename escaping and parsing used today by setuptools and compatible tools, and will produce inconsistent comparisons between "rational" versions and the version schemes supported by setuptools. Ideally, it would be best to keep PEP 386 versions a strict subset of setuptools-supported versions, to minimize migration difficulties.

Ben Finney schrieb:

Eric Smith writes:

...

Ben Finney wrote:

...

That is, you want me to propose an example version string X. I'm asking for you to tell me corresponding examples of version strings W and Y where:

W < X < Y

since the comparison semantics are what we're discussing here.

W = 3.3.0 Y = 3.3.1

If you're going to suggest 3.3.0.99 or some such

Yes. Or any version string that would obviously fall between the two.

A specific version comparison scheme will never be obvious to all people at the same time. However we can provide one that is obvious to *most*, and it is not the one you're pushing.

...

I think that won't work. It's important that code sees that as 3.3.1.<something>. I've seen code that fails when the pre-release versions have a different MAJOR.MINOR.MICRO than the final version.

It's exactly that kind of code that I don't feel needs to be accommodated. It's clearly causing ambiguities and contortions, and now we talk about needing Python-specific version comparison algorithms in order to automate the comparison.

The need for pre/post-release versions is hardly Python-specific. It is used by a large fraction of developers in some way or other.

Why is this worth the trouble, when the standard could simply describe obvious-to-everyone version comparison semantics that are far easier for everyone to get right?

Very true. Surely, it will be obvious to everyone that 3.1alpha1 is a version greater than 3.1. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

P.J. Eby wrote:

At 08:11 PM 11/28/2009 +0100, M.-A. Lemburg wrote:

...

Tarek Ziadé wrote:

...

On Thu, Nov 26, 2009 at 1:08 PM, M.-A. Lemburg wrote:

...

Here's another take at a minimal change to the format which includes the things we discussed, adds a few more aliases for the "post" and "dev" markers and also adds optional underscores for more readability.

Please don't add underscores to the syntax -- they will cause problems with the filename escaping and parsing used today by setuptools and compatible tools, and will produce inconsistent comparisons between "rational" versions and the version schemes supported by setuptools.

Ideally, it would be best to keep PEP 386 versions a strict subset of setuptools-supported versions, to minimize migration difficulties.

Filename parsing is a bad idea to begin with. The meta data incorporated into file names should be read from a meta data file or database instead, with the filename just being another parameter in the set of meta data parameters. Frankly, we are defining a standard for *distutils* and new packages here - so I'm not sure in what way setuptools compatibility can be used as argument for limiting the readability of a new standard. OTOH, I'm sure that by the time distribute can take over the role of setuptools, such limitations will have been lifted. Besides, setuptools users can, of course, continue to use version strings without embedded underscores. Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 29 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/

At 02:34 PM 11/29/2009 +0100, M.-A. Lemburg wrote:

P.J. Eby wrote:

...

At 08:11 PM 11/28/2009 +0100, M.-A. Lemburg wrote:

...

Tarek Ziadé wrote:

...

On Thu, Nov 26, 2009 at 1:08 PM, M.-A. Lemburg wrote:

...

Here's another take at a minimal change to the format which includes the things we discussed, adds a few more aliases for the "post" and "dev" markers and also adds optional underscores for more readability.

Please don't add underscores to the syntax -- they will cause problems with the filename escaping and parsing used today by setuptools and compatible tools, and will produce inconsistent comparisons between "rational" versions and the version schemes supported by setuptools.

Ideally, it would be best to keep PEP 386 versions a strict subset of setuptools-supported versions, to minimize migration difficulties.

Filename parsing is a bad idea to begin with.

Practicality beats purity.

Frankly, we are defining a standard for *distutils* and new packages here - so I'm not sure in what way setuptools compatibility can be used as argument for limiting the readability of a new standard. OTOH, I'm sure that by the time distribute can take over the role of setuptools, such limitations will have been lifted.

Unless we're talking about strictly Python 3 here (in which case all bets are off and compatibility isn't a prime concern) Distribute is limited by the need to be able to consume setuptools-based packages, or it loses a key user incentive (i.e., its "just works"-ness).

Besides, setuptools users can, of course, continue to use version strings without embedded underscores.

Setuptools users also consume other people's packages, which means they will wind up with bad version comparisons in that case. And Distribute can't work around this unless it escapes underscores as some other character when it makes files for consumption by those tools, since it will otherwise lose the ability to parse those versions when they come back in. If you want mass uptake of a standard, you need to take these sort of things into consideration; incentive engineering is not optional when you want grass-roots support for an independently-created standard. WSGI and setuptools have been widely adopted in spite of their technical and ideological flaws, because they had good incentive engineering. Or, in other words, because practicality beats purity, every single time.

Tarek Ziadé wrote:

Last, as I said in a previous mail, I tend to agree with the people who said that we should stick with only one way to write the version scheme for the sake of clarity. e.g. dropping aliases and picking *one* way to write the markers after major.minor.micro.

I would tend to pick the same scheme than Python for the pre-releases (and c + rc):

N.N[.N][(a|b|c|rc)N]

And, for the post/dev markers I think dots are OK for readability,

Sure, but readability and clarity means different things for different people. The reason I proposed aliases and underscores is to give package authors the choice of using terse forms or more verbose ones, as well as making the whole scheme more compatible to existing version strings already in use. Regarding post/dev markers: IMO, it's not really obvious that a 1.0a1.dev123 release refers to a snaphost *before* the 1.0a1 release. The string "pre" is more commonly used for such pre-release snapshots. For the .post123 tag, I don't see a need for a "post" string at all, 1.0a1.123 is clearly a release or build *after* the 1.0a1 release and since the "1.123" is being treated as alpha version number, the post part processing can be dropped altogether. For the .dev part the situation is similar: you can always choose a pre-release version that is not actually released and then issue follow up snapshots to this, e.g. 1.0a0.20091203 1.0a0.20091204 1.0a0.20091205 and so on for nightly builds during the development phase. Instead of writing: 1.0a1.dev20091205 you'd then write 1.0a0.20091205 This is how Python itself is organizing the versions during development, BTW. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 03 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/

On Thu, Dec 3, 2009 at 1:55 PM, M.-A. Lemburg wrote:

Tarek Ziadé wrote:

...

Last, as I said in a previous mail, I tend to agree with the people who said that we should stick with only one way to write the version scheme for the sake of clarity. e.g. dropping aliases and picking *one* way to write the markers after major.minor.micro.

I would tend to pick the same scheme than Python for the pre-releases (and c + rc):

    N.N[.N][(a|b|c|rc)N]

And, for the post/dev markers I think dots are OK for readability,

Sure, but readability and clarity means different things for different people.

The reason I proposed aliases and underscores is to give package authors the choice of using terse forms or more verbose ones, as well as making the whole scheme more compatible to existing version strings already in use.

Regarding post/dev markers:

IMO, it's not really obvious that a 1.0a1.dev123 release refers to a snaphost *before* the 1.0a1 release. The string "pre" is more commonly used for such pre-release snapshots.

For the .post123 tag, I don't see a need for a "post" string at all, 1.0a1.123 is clearly a release or build *after* the 1.0a1 release and since the "1.123" is being treated as alpha version number, the post part processing can be dropped altogether.

For the .dev part the situation is similar: you can always choose a pre-release version that is not actually released and then issue follow up snapshots to this, e.g.

       1.0a0.20091203        1.0a0.20091204        1.0a0.20091205

and so on for nightly builds during the development phase.

Instead of writing:

       1.0a1.dev20091205

you'd then write

       1.0a0.20091205

This is how Python itself is organizing the versions during development, BTW.

So IOW, are you suggesting that a suffix marker is always a post release marker ? so we have : 1.0a0 < 1.0a0.124 < 1.0a0.245 < 1.0a1 < 1.0a1.346 < 1.0a2 < 1.0 < 1.0.567 <--- dev marker The problem in that case is that we would be unable to differenciate dev marker with micro markers. That's why we added these "dev" markers in the first place. So following your ordering: - 1.0a0 < 1.0a0.dev124 < 1.0a0.dev245 < 1.0a1 < 1.0a1.dev346 < 1.0a2 < 1.0 < 1.0.dev567 <--- dev marker Now about making the dev a post release tag, AFAIK people always use dev markers as pre-release tags: - 1.0a0 < 1.0a1.dev124 < 1.0a1.dev245 < 1.0a1 < 1.0a2.dev346 < 1.0a2 < 1.0.dev567 <--- dev marker < 1.0 Last, if we want to do a post release for 1.0 for example, you would also need a post- marker, as we added Regards Tarek

Toshio Kuratomi wrote:

On Thu, Dec 03, 2009 at 01:55:53PM +0100, M.-A. Lemburg wrote:

...

Tarek Ziadé wrote:

...

Last, as I said in a previous mail, I tend to agree with the people who said that we should stick with only one way to write the version scheme for the sake of clarity. e.g. dropping aliases and picking *one* way to write the markers after major.minor.micro.

I would tend to pick the same scheme than Python for the pre-releases (and c + rc):

N.N[.N][(a|b|c|rc)N]

And, for the post/dev markers I think dots are OK for readability,

Sure, but readability and clarity means different things for different people.

The reason I proposed aliases and underscores is to give package authors the choice of using terse forms or more verbose ones, as well as making the whole scheme more compatible to existing version strings already in use.

I'm not a big fan of underscores -- having multiple separators doesn't seem very useful.

I'm not tied to those underscores, just think they'd help in making the strings more readable.

I don'tlike aliases but seeing as I like the long forms, having both short and long but giving them a distinct ordering would be okay to me (ie:

a1 < alpha1 < a2 < b1 < beta1 < c1 < rc1

That would also work. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 03 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/

Tarek Ziadé wrote:

[..]

...

1. whether it's release quality code

1.0.0

2. whether it's a development snapshot

1.0.0a0.20091202

3. whether it's working code, but still under development

1.0.0a1

4. whether it fixes some bug that was found after a release

1.0.1

How do you explicitely know here that "1.0.1" is a final release ?

it could be a dev snapshot of "1.0"

No, dev snapshots of 1.0 would be marked as: 1.0.0a0.123

Unless you are suggesting that snapshots are always timestamps, but that's just one way to number snapshots.

Snapshots can use any number format they like - as long as it's numeric, e.g. timestamps, subversion revision numbers, etc. Not hq hex revisions, I'm afraid, unless there's a standard way to express them as (monotone) numbers as well.

[..]

...

If you want to then work on release 1.1, you'd continue with:

- 1.0.567 < 1.1a0 (which is not released and only used to mark the start of 1.1 development, just like we do for Python) < 1.1a0.124 < 1.1a0.245 < 1.1a1 (pre-release) < 1.1a1.346 < 1.1a2 (pre-release) < 1.1 (release)

As you can see, you don't need any dev-markers and post-markers turn into pre-release minor version numbers... less noise, more clarity, well at least IMHO.

I see your point but the problem I see is that you are unable to explicitely make a difference between development snapshots and final releases, because projects can use three levels for their final releases:

MAJOR or MAJOR.MINOR or MAJOR.MINOR.MICRO

so if snapshots are only numbers, they can't be explicitely differenciated.

IOW: 1.0.10 can be two things here, if I get it right:

- a snapshot release of 1.0 - the 1.0.10 final release

So end-users and packagers will not know if they deal with a final release or not.

A snapshot will always be a version of a pre-release, so it's clear that you get a snapshot when looking at: 1.0.0a0.123 (the "a0" signals the pre-release status) OTOH, versions without pre-release marker are always release versions, e.g. 1.0.0 1.0.0.123 1.0.0.123.0.456 (with whatever meaning those added levels may have, e.g. could be build numers, branch version numbers, etc.) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 03 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/

On Thu, Dec 3, 2009 at 5:19 PM, M.-A. Lemburg wrote: [..]

A snapshot will always be a version of a pre-release, so it's clear that you get a snapshot when looking at:

       1.0.0a0.123

(the "a0" signals the pre-release status)

OTOH, versions without pre-release marker are always release versions, e.g.

       1.0.0        1.0.0.123        1.0.0.123.0.456

(with whatever meaning those added levels may have, e.g. could be build numers, branch version numbers, etc.)

I am with Floris here, I think dev/post markers are more explicit than "a0" and implicit markers. And we will always have a hundred ways of doing this. Last, as long as people schemes can be translated to PEP 386, wer'e safe. I propose to end this thread here, and to start a new thread on Python-dev for PEP 386 as I mentioned previously. So, eventually we can decide there on a final scheme, then focus on the last details on PEP 345. I will post the mail for python-dev here so people can check it before it is sent, Regards Tarek