Re: [Distutils] Common version-comparison semantics for peace love and harmony
In a message of Sat, 28 Nov 2009 10:27:14 +0100, Tarek Ziadé writes:
On Sat, Nov 28, 2009 at 7:31 AM, Laura Creighton <lac@openend.se> wrote:
It occurs to me that this problem would go away if we had a way to ask, for any given version number, 'what was your creation date' and the sorting 'earlier' and 'later' by that date. Can somebody explain why we aren't doing this?
You mean like a timestamp before or after the version ?
I might be wrong but I think that would be similar to what RPM calls an Epoch. A number that can be used to compare two packages when their versions number don't follow the standard scheme anymore. But that's just a fallback. But for the sake of simplicity and standardization, this extra number is avoided.
Meaning that it would be better to define and use a standard for the released packages, than introducing a timestamp and say: do whatever you want with your version numbers.
But I think that it is the other way around ... what we want is a timestamp. The algorithm is for guessing which version is ealier in the absence of a timestamp.
At some point, we all agree that MAJOR.MINOR.MICRO is an accepted standard and we are arguing about pre/post/dev releases.
We have no way to enforce this on the world. The arguments here may have gone away, but out in the wild, I think we need to accept that people are going to name their packages whatever they like. We can suggest in the strongest possible terms that they use this numbering convention, but it will still just be a suggestion.
My point is that we are able to define a public scheme for those too, so all package installers share the same conventions.
This doesn't imply that developers have to use it internally. It just implies that, if the developer releases his package at some point to PyPI, he will know *how* his version number will be sorted by package managers, because it's documented in a PEP. e.g. a shared convention.
It's not that I am 'anti-convention', it is just that I think that if we include a timestamp, and use that _first_ when trying to find out if a package is earlier than another package, then we will be able to interoperate with those people who out of ignorance or some business reason cannot respect the convention. Laura
Regards Tarek
2009/11/28 Laura Creighton <lac@openend.se>:
In a message of Sat, 28 Nov 2009 10:27:14 +0100, Tarek Ziadé writes:
On Sat, Nov 28, 2009 at 7:31 AM, Laura Creighton <lac@openend.se> wrote:
It occurs to me that this problem would go away if we had a way to ask, for any given version number, 'what was your creation date' and the sorting 'earlier' and 'later' by that date. Can somebody explain why we aren't doing this?
You mean like a timestamp before or after the version ?
I might be wrong but I think that would be similar to what RPM calls an Epoch. A number that can be used to compare two packages when their versions number don't follow the standard scheme anymore. But that's just a fallback. But for the sake of simplicity and standardization, this extra number is avoided.
Meaning that it would be better to define and use a standard for the released packages, than introducing a timestamp and say: do whatever you want with your version numbers.
But I think that it is the other way around ... what we want is a timestamp. The algorithm is for guessing which version is ealier in the absence of a timestamp.
At some point, we all agree that MAJOR.MINOR.MICRO is an accepted standard and we are arguing about pre/post/dev releases.
We have no way to enforce this on the world.
Actually, there is: refuse any packages on pypi which does not follow the standard. In exchange of using the standard (whatever it ends up being), you can use pypi. David
[Laura Creighton, 2009-11-28]
what we want is a timestamp. The algorithm is for guessing which version is ealier in the absence of a timestamp.
do you want to use timestamps only to sort versions? Consider this example: 1.0 timestamp=20090323 2.0 timestamp=20090618 1.1 timestamp=20091128 (fix in 1.x branch) how would you sort it? -- 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 10:50:36AM +0100, Laura Creighton wrote:
But I think that it is the other way around ... what we want is a timestamp. The algorithm is for guessing which version is ealier in the absence of a timestamp.
Does this work when you have a two maintenance branches releasing in parallel? Consider this example: 2009-01-01: 1.0 2009-02-01: 1.1 2009-02-20: 1.0.1 (1.0 maint branch) 2009-02-21: 1.1.1 (1.1 maint branch) Regards Floris
On Nov 28, 2009, at 4:50 AM, Laura Creighton wrote:
At some point, we all agree that MAJOR.MINOR.MICRO is an accepted standard and we are arguing about pre/post/dev releases.
We have no way to enforce this on the world. The arguments here may have gone away, but out in the wild, I think we need to accept that people are going to name their packages whatever they like. We can suggest in the strongest possible terms that they use this numbering convention, but it will still just be a suggestion.
I think the PEP should lay out a standard scheme, the Python standard library (distutils) should have the tools to support it, and either conform to it or not at your product and your user's peril. Other than providing tools to suggest a PEP compliant version for you that is as close to your current version as possible, I don't think we should support ANY other versioning scheme but the rational one laid out in the PEP, period. Once the bikeshed is built and painted, throw away all the other exotic materials and paint colors. How about if we make it a suggestion like this: If you want your tools to be installable in a reliable way, using standard Python installation tools, so that your users always know that they are getting the exact version that they want, and so they can install things from PyPi, the Python standard code repository, we suggest that you follow the PEP 386 versioning scheme. The PEP 386 scheme will be supported by a broad range of tools including Python's distutils, the Distribute installation system, and any other tools using the Python standard library routines for versioning. Otherwise, we suggest that you devote a large amount of time preparing an extremely detailed explanation about why you chose not to follow a community standard and also either provide your own comprehensive installation tools, or explain exactly how to use standard Python installation tools with your non-standard versioning scheme. Also, please write a FAQ about exactly how to determine exactly which version of your product is installed and how to determine what the "next" and "previous" versions are since the users can't determine that using the standard Python tools or reading the Python documentation. Ok? It's just a suggestion. Feel free to make it as difficult for yourself and your users by inventing whatever scheme seems best to you and best of luck with that. S
At 10:50 AM 11/28/2009 +0100, Laura Creighton wrote:
But I think that it is the other way around ... what we want is a timestamp. The algorithm is for guessing which version is ealier in the absence of a timestamp.
You're assuming a process with no branches, where e.g. version 1.2 is being updated while 2.0 is being developed. Timestamps are not a general substitute for versions.
participants (6)
-
David Cournapeau -
Floris Bruynooghe -
Laura Creighton -
P.J. Eby -
Piotr Ozarowski -
ssteinerX＠gmail.com