PEP 386 status - last round here ?
Hello, PEP 386 seem to be ready, and I would like to push if for feedback at python-dev, just before PEP 345 is pushed. My only concern is now to make sure the PEP motivations and explanations are crystal clear. Anyone see any problem ? or have any concern with this PEP ? This PEP is the basis for PEP 345 acceptation. Regards Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
On Tue, Nov 24, 2009 at 10:50 AM, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
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) ?
This behavior will not be affected. 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 Tarek
cheers,
David
-- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
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 Nov 24, 2009, at 4:47 AM, Tarek Ziadé wrote:
Hello,
PEP 386 seem to be ready, and I would like to push if for feedback at python-dev, just before PEP 345 is pushed.
My only concern is now to make sure the PEP motivations and explanations are crystal clear.
Anyone see any problem ? or have any concern with this PEP ?
I think the motivation and explanations are clear. 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' ? 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... 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). 4> The [#requrires] reference is missing from the README.txt file 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. S
On Tue, Nov 24, 2009 at 2:31 PM, ssteinerX@gmail.com <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
On Nov 24, 2009, at 3:40 PM, Tarek Ziadé wrote:
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)
4> The [#requrires] reference is missing from the README.txt file I'll update it using the latest PEP 376 text
Ok, I'll look for those when I pull later tonight?
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,
May I have access please?
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.
Ok, it would be great to have an example of an RPM or deb package showing the direct translation but no big deal. S
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/
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.
-- 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 <mal@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. 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 <mal@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. 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 <mal@egenix.com> wrote:
Tarek Ziadé wrote:
2009/11/25 M.-A. Lemburg <mal@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
Tarek Ziadé wrote:
On Wed, Nov 25, 2009 at 9:04 PM, M.-A. Lemburg <mal@egenix.com> wrote:
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
Ok.
[..]
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]
Shouldn't we leave defining the meaning of those tags to the developers ? IMHO, descriptive names are better than single letter abbreviations. BTW: How would you name a snapshot using the scheme ? Say you are working on an upcoming version 3.2.0 of a package and you use the date as snapshot indicator (as opposed to some revision, which doesn't have any meaning for an end-user). I suppose this is the only way: 3.2.0a0.20091125 ... not very obvious :-( 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 :-) -- 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:52 PM, M.-A. Lemburg <mal@egenix.com> 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 <mal@egenix.com> 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/
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 :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 26 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 <mal@egenix.com> 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
Tarek Ziadé wrote:
On Thu, Nov 26, 2009 at 1:08 PM, M.-A. Lemburg <mal@egenix.com> 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
I haven't made any changes to verlib, only to the RE. Here's the test for it: import re 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) test = """\ 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 """ testcases = [x.strip() for x in test.split()] comp = None version = None for x in testcases: if x in '<=': continue assert VERSION_RE.match(x), x -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 28 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 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 <mal@egenix.com> 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.
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 <mal@egenix.com> 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/
2009/11/29 M.-A. Lemburg <mal@egenix.com>: [..]
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.
Notice that the metadada files added during installation are the ones that will be used to query installed distributions (see PEP 376) Their syntax is currently : name + '-' + version + '.egg-info' , with all occurences of "-" in the name being escaped by "_". So I don't see any technical problem in using "-" in the version, as long as the first "-" in the egg-info name can be used to be able to extract the name and version of the project. *But*, on a second thought, I don't see any problem in completely removing the version from the egg-info filename in PEP 376, since looping on *.egg-info files suffices for our APIs, and since we said that we didn't want to support multiple versions.
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.
Yes, Distribute will follow all PEPs as soon as they are accepted, 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, Tarek
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 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 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
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.
FWIW, I agree with all of this section. -Toshio
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/
On Thu, Dec 3, 2009 at 1:55 PM, M.-A. Lemburg <mal@egenix.com> 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
Tarek Ziadé wrote:
On Thu, Dec 3, 2009 at 1:55 PM, M.-A. Lemburg <mal@egenix.com> 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 ?
In a way, yes. For pre-releases, it's actually a minor revision of the pre-release version, e.g. in 1.0a0.123 the "0.123" part is the pre-release version. For releases, it's a normal part of the version number, e.g. in 1.0.123 the ".123" marks a patch level release.
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
That's not a dev-marker, it's actually part of the release version: the patch level release number.
The problem in that case is that we would be unable to differenciate dev marker with micro markers.
The dev markers introduce an extra level of confusion, which IMHO is not necessary. Let's take 1.0a0.dev123 as example, reading it from the left: 1.0 - ok, so this is part of a 1.0 release 1.0a0 - oops, no, it's not actually part of a release, it's part of a pre-release, so move back 1.0a0.dev123 - hmm, not even that, it's part of what's going to become a pre-release, so move even further back As developer you typically want to use the version number to tell the user a few things about your package: 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
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
Sorry, I probably wasn't clear enough. What I proposed looks like this: 1.0a0 (which is not released and only used to mark the start of 1.0 development, just like we do for Python) < 1.0a0.124 < 1.0a0.245 < 1.0a1 (pre-release) < 1.0a1.346 < 1.0a2 (pre-release) < 1.0 (release) < 1.0.567 (release) and the 1.0.567 is not a dev-marker (since the proposal is about removing these ;-), but instead a post-marker without the "post". In reality, such a post release would be a patch-level release. 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. -- 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/
[..]
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" Unless you are suggesting that snapshots are always timestamps, but that's just one way to number snapshots. [..]
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. Regards Tarek
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 <mal@egenix.com> 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
On Thu, Dec 03, 2009 at 04:50:50PM +0100, M.-A. Lemburg wrote:
The dev markers introduce an extra level of confusion, which IMHO is not necessary.
Let's take 1.0a0.dev123 as example, reading it from the left:
1.0 - ok, so this is part of a 1.0 release 1.0a0 - oops, no, it's not actually part of a release, it's part of a pre-release, so move back 1.0a0.dev123 - hmm, not even that, it's part of what's going to become a pre-release, so move even further back
This is a weak argument IMHO, because your proposal doesn't change that and this is also the way people are used too anyway ("something.alpha" has been understood to come before "something" for a long time by most people).
As developer you typically want to use the version number to tell the user a few things about your package:
1. whether it's release quality code
1.0.0
ack
2. whether it's a development snapshot
1.0.0a0.20091202
or 1.0.0a0.dev20091202 or 1.0.0a0.post20091202 (or with your case of not releasing an a0 also 1.0.0a1.dev20091202). None of these are more confusing really.
3. whether it's working code, but still under development
1.0.0a1
ack
4. whether it fixes some bug that was found after a release
1.0.1
ack
Sorry, I probably wasn't clear enough. What I proposed looks like this:
1.0a0 (which is not released and only used to mark the start of 1.0 development, just like we do for Python) < 1.0a0.124 < 1.0a0.245 < 1.0a1 (pre-release) < 1.0a1.346 < 1.0a2 (pre-release) < 1.0 (release) < 1.0.567 (release)
and the 1.0.567 is not a dev-marker (since the proposal is about removing these ;-), but instead a post-marker without the "post". In reality, such a post release would be a patch-level release.
Sure you can create a release process entirely with post-release style tags. But the PEP explicitly tried to cater for both styles. In the original discussion different projects using the different systems where mentioned and in the end it was found that it was not that strange, contradictory or harming to support both. As I understand it you can follow the release process that you like already with PEP 386, and that is what is important: the proposal is capable to express the versions you desire. You can happily ignore .devXXX and others can happily use it. The only problem you then have left is that you can type .postXXX but achieve the same with just adding .XXX to the number already (as you prefer). While it is true that you could get rid of .postXXX without losing the ability to express some version numbers it was felt (all of this from my memory from original discussions - apologies if I misrepresent something) that the symmetry of .postXXX and .devXXX are actually nice. Lastly the sin of having two ways of specifying post-release tags is eased by them having a strictly defined order. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org
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 <mal@egenix.com> 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.
2009/11/29 P.J. Eby <pje@telecommunity.com>: [..]
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.
Do you mean here that this independently-created standard, this good incentive engeneering a.k.a. Setuptools, is doomed not to evolve anymore ? e.g. to adapt its standard to a common standard that is going to raise and be added in stldib at some point ? That's not what Distribute will aim at. We will want to provide the compatibility bridge for people that uses setuptools API to adopt the upcoming standards. And if this happen in Python 2.7, that might be a simple flag : use_stdlib_standard = True IOW third party software should adapt themselves to Python and its stdlib, through deprecations etc., not the contrary. Regards, Tarek
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.
< 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
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)
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 :-)
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'. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org
On Thu, Nov 26, 2009 at 8:55 PM, Floris Bruynooghe <floris.bruynooghe@gmail.com> 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
[Tarek Ziadé, 2009-11-26]
On Thu, Nov 26, 2009 at 8:55 PM, Floris Bruynooghe <floris.bruynooghe@gmail.com> 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 ... [0] dpkg --compare-versions '1.0~a1~dev456' '<=' '1.0~a1+dev456' && echo true || echo false -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
On Fri, Nov 27, 2009 at 11:39 AM, Piotr Ozarowski <ozarow@gmail.com> wrote:
[Tarek Ziadé, 2009-11-26]
On Thu, Nov 26, 2009 at 8:55 PM, Floris Bruynooghe <floris.bruynooghe@gmail.com> 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
On Fri, Nov 27, 2009 at 1:24 PM, Tarek Ziadé <ziade.tarek@gmail.com> 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)
Tarek Ziadé <ziade.tarek@gmail.com> 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 <ben+python@benfinney.id.au> wrote:
Tarek Ziadé <ziade.tarek@gmail.com> 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
Tarek Ziadé <ziade.tarek@gmail.com> writes:
On Fri, Nov 27, 2009 at 1:52 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
I'd like to register, once again, the point that [translating PEP 386 version comparison semantics to existing semantics] 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.
Not sure what you mean by special keywords. If it's about 'post' and 'dev'
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. 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? -- \ “Alternative explanations are always welcome in science, if | `\ they are better and explain more. Alternative explanations that | _o__) explain nothing are not welcome.” —Victor J. Stenger, 2001-11-05 | Ben Finney
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?
Eric Smith <eric@trueblade.com> 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? -- \ “All opinions are not equal. Some are a very great deal more | `\ robust, sophisticated and well supported in logic and argument | _o__) than others.” —Douglas Adams | Ben Finney
Ben Finney wrote:
Eric Smith <eric@trueblade.com> 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 <eric@trueblade.com> 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
Ben Finney wrote:
Eric Smith <eric@trueblade.com> 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 <eric@trueblade.com> 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
Ben Finney schrieb:
Eric Smith <eric@trueblade.com> 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.
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.
"P.J. Eby" <pje@telecommunity.com> writes:
At 10:32 AM 11/28/2009 +1100, Ben Finney wrote:
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.
My understanding of PEP 386 is that it *isn't* about asking Python developers to change how they work. Is that not right?
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. 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. -- \ “Our task must be to free ourselves from our prison by widening | `\ our circle of compassion to embrace all humanity and the whole | _o__) of nature in its beauty.” —Albert Einstein | Ben Finney
At 12:26 PM 11/28/2009 +1100, Ben Finney wrote:
I think you're reading a proposal that I didn't write.
Are you not the person who's proposed using simple alphanumeric strings for version comparison?
My understanding of PEP 386 is that it *isn't* about asking Python developers to change how they work. Is that not right?
Asking them to generate alternative versioning schemes, without the ability to use pre-release versions (e.g. alpha, beta, etc.) would most certainly be a change from the status quo.
Moreover, what is a standard for if not for encouraging people to follow it for the benefit of many?
Usually, they get something in trade. Supporting WSGI means you get to use WSGI apps, or run on a WSGI server, for example. So, cost and benefit are balanced. In contrast, a popular Python library or app will get packaged if somebody wants it, and not if they don't. There isn't a lot of incentive for a developer to do something different, solely for the sake of the packager... which is probably why things are the way they are now. If, on the other hand, there's some positive benefit being offered (e.g. a new tool that makes life easier for them or perhaps their users), then there might be some incentive to learn a new way of coding versions. But without such an incentive, who wants to learn some new way to encode prerelease versions? 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().
"P.J. Eby" <pje@telecommunity.com> writes:
At 12:26 PM 11/28/2009 +1100, Ben Finney wrote:
My understanding of PEP 386 is that it *isn't* about asking Python developers to change how they work. Is that not right?
Asking them to generate alternative versioning schemes, without the ability to use pre-release versions (e.g. alpha, beta, etc.) would most certainly be a change from the status quo.
We seem to be talking entirely past each other; I can't see how to relate what I wrote to your reply. -- \ “Programs must be written for people to read, and only | `\ incidentally for machines to execute.” —Abelson & Sussman, | _o__) _Structure and Interpretation of Computer Programs_ | Ben Finney
On Sat, Nov 28, 2009 at 4:00 AM, P.J. Eby <pje@telecommunity.com> wrote:
At 12:26 PM 11/28/2009 +1100, Ben Finney wrote:
I think you're reading a proposal that I didn't write.
Are you not the person who's proposed using simple alphanumeric strings for version comparison?
My understanding of PEP 386 is that it *isn't* about asking Python developers to change how they work. Is that not right?
Asking them to generate alternative versioning schemes, without the ability to use pre-release versions (e.g. alpha, beta, etc.) would most certainly be a change from the status quo.
Moreover, what is a standard for if not for encouraging people to follow it for the benefit of many?
Usually, they get something in trade. Supporting WSGI means you get to use WSGI apps, or run on a WSGI server, for example. So, cost and benefit are balanced.
In contrast, a popular Python library or app will get packaged if somebody wants it, and not if they don't. There isn't a lot of incentive for a developer to do something different, solely for the sake of the packager... which is probably why things are the way they are now.
If, on the other hand, there's some positive benefit being offered (e.g. a new tool that makes life easier for them or perhaps their users), then there might be some incentive to learn a new way of coding versions. But without such an incentive, who wants to learn some new way to encode prerelease versions?
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().
Yes, this function can be used internally, and that was a good idea to have that function. But as soon as it is used inside a public package manager, like pip or setuptools or distribute, I expect this function to raise some kind of warning so the developers knows its version doesn't meet the public, documented standard.
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. 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. Regards Floris
On Sat, Nov 28, 2009 at 12:28 PM, Floris Bruynooghe <floris.bruynooghe@gmail.com> 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 05:07:01PM +0100, Tarek Ziadé wrote:
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)
+1
2 - keep the aliases (alpha/beta/rc) because they are not controversial
Rather than aliases, I'd like to see a sort order worked out. Someone will make both foo-1.0alpha1 and foo-1.0a1 because they don't understand that they're just supposed to be aliases. Better to document explicitly what happens in that case.
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.
+1
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.
Agreed :-) -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 <floris.bruynooghe@gmail.com> 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
Tarek Ziadé <ziade.tarek@gmail.com> writes:
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.
I disagree on both counts — these keywords are not needed, and are not harmless — and have demonstrated otherwise, so I am convinced the above conclusion is a mistake. However, I don't intend to repeat the discussion further (rejoice!). Do with the information what you will. -- \ “I washed a sock. Then I put it in the dryer. When I took it | `\ out, it was gone.” —Steven Wright | _o__) | Ben Finney
On Sat, Nov 28, 2009 at 10:53 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
Tarek Ziadé <ziade.tarek@gmail.com> writes:
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.
I disagree on both counts — these keywords are not needed, and are not harmless — and have demonstrated otherwise, so I am convinced the above conclusion is a mistake.
Sorry I failed to understand your demonstration. I fail to see how the version scheme is useful and can be used by developers without dev and post versions, and how these keywords are not needed. Regards, Tarek
On Sat, Nov 28, 2009 at 2:26 AM, Ben Finney <ben+python@benfinney.id.au> 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
On Sat, Nov 28, 2009 at 2:02 AM, P.J. Eby <pje@telecommunity.com> wrote:
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.
That's completely wrong, the proposal is a benefit for all of us, because it standardizes something that is already being done. PEP 386 propose a scheme to be adopted by developers or tools, but if some people want to stick with their own internal version scheme for development versions or post/pre release versions, they can do it without any problem. And they don't have to follow any PEP 386 convention for their internal work. And when they release their projects, if they stick with MAJOR.MINOR.MICRO, it will work. But as soon as they publish development versions, or post or pre releases, they have two choice: - they use a standard that is described in PEP 386 - so their package is installable by installers that follow it - they provide documentation about their own internal standard Today, if they release their package with their own custom version scheme, setuptools will just install those package, and screw the ordering if it doesn't follow its heuristic version sorter. So PEP 386 is just about describing a standard for something that is already being done: installing versioned distributions in someone's computer. Tarek
On Sat, Nov 28, 2009 at 12:32 AM, Ben Finney <ben+python@benfinney.id.au> 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.
[Tarek Ziadé, 2009-11-27]
On Fri, Nov 27, 2009 at 1:24 PM, Tarek Ziadé <ziade.tarek@gmail.com> 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)
We use that as well. Epoch cannot be used here, though (IMO). Unless you're talking about segment's epoch, not the whole version one, but then, "-" and "+" will be still much easier for rpm. Let's wait for Toshio's reply...
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)
that would be nice, but we still have to implement it on our side, f.e. in tools like uscan (or in its configuration files: debian/watch). uscan scans upstream repositories (like PyPi) for new tarballs, then uses regular expressions to change the versions, compares them and downloads/renames/notifies maintainer. My point is: it's easier to feed uscan with s/-/~/g instead of s/rc/~rc/;s/\<c/~rc/g;s/\<a/~a/g;... but it's not a very big problem - we handle much uglier upstream version shemas ;-). If all pypi packages would use the same rules, it would allow us to handle it in uscan instead of in per package basis (debian/watch files), though. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
On Nov 27, 2009, at 7:31 AM, Tarek Ziadé wrote:
On Fri, Nov 27, 2009 at 1:24 PM, Tarek Ziadé <ziade.tarek@gmail.com> 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... What would that API have to look like? Maybe start a doc in the repo to hold that spec as we develop it? 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. S
On Fri, Nov 27, 2009 at 3:31 PM, ssteinerX@gmail.com <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é <ziade.tarek@gmail.com> 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
[ssteinerX@gmail.com, 2009-11-27]
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?
used where? In Debian we don't touch upstream code in order to adjust it to our version schema, so although package version is 4:0.1~alpha1+r23-5 module.__version__ still returns 0.1alpha1 or 0.1a.svn23. It only matters for tools like uscan that look for new upstream releases and prepare tarball names for us. Please also note that such translations can only be a hint, you cannot rely on it. Imagine situation where upstream author changes version schema from YYYYMMDD to X.Y.Z, we simply bump epoch so after 20091127-1 comes 1:5.6.7-1, how would you know that epoch bump was needed without knowing the history of the package? We cannot really trust versions in requires.txt/install_requires/etc. either (so there's no need to translate them) as we have to double check these versions in most modules anyway (they're usually too low, too high or simply missing). -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
On Nov 27, 2009, at 9:58 AM, Piotr Ozarowski wrote:
[ssteinerX@gmail.com, 2009-11-27]
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?
used where?
I'm thinking of a tool, callable within *any* build process, for verifying that the version conforms to the "RationalVersion" scheme, for example. Especially, I'm interested in a tool that would automatically increment version numbers for e.g. in process development versions where each build needs a new version number (maybe in several places e.g. setup.py, documentation, history file, etc.). 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 <ozarow@gmail.com> wrote:
[Tarek Ziadé, 2009-11-26]
On Thu, Nov 26, 2009 at 8:55 PM, Floris Bruynooghe <floris.bruynooghe@gmail.com> 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
On Fri, Nov 27, 2009 at 8:55 PM, Toshio Kuratomi <a.badger@gmail.com> 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. 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.
?) Where does 1.0-post123 fall in your list?
post would always be prefixed by "+" in Piotr release IIRC Regards Tarek
[Tarek Ziadé, 2009-11-28]
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.
yup -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
On Sat, Nov 28, 2009 at 04:27:04PM +0100, Tarek Ziadé wrote:
On Fri, Nov 27, 2009 at 8:55 PM, Toshio Kuratomi <a.badger@gmail.com> 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
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 Wed, Nov 25, 2009 at 09:52:45PM +0100, M.-A. Lemburg wrote:
BTW: How would you name a snapshot using the scheme ?
Say you are working on an upcoming version 3.2.0 of a package and you use the date as snapshot indicator (as opposed to some revision, which doesn't have any meaning for an end-user).
I suppose this is the only way:
3.2.0a0.20091125
... not very obvious :-(
I think it would be this: 3.2.0a0.dev20091125 But given that you came up with something else the non-obvious argument might be valid.
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 :-)
Now this would be 3.2.0.dev20091125 Regards Floris
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
ssteinerX@gmail.com wrote:
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.
The meaning of the version modifiers is not really relevant here. distutils just needs to be able to compare them and not make mistakes in those comparisons. Also note that distutils won't be comparing apples and oranges, only the version numbers of a single package. Given that package authors typically don't change their versioning scheme within a single release cycle, there's nothing much to worry about, IMO. -- 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/
participants (11)
-
Ben Finney -
David Cournapeau -
Eric Smith -
Floris Bruynooghe -
Georg Brandl -
M.-A. Lemburg -
P.J. Eby -
Piotr Ozarowski -
ssteinerX＠gmail.com -
Tarek Ziadé -
Toshio Kuratomi