Tarek Ziadé
There's a consensus on this in most packaging system out there, and the goal is to have a rational version system that is understandable by most packagers so they can work with python projects versions.
Have you actually read the version comparison specifications of other packaging systems? How do you think they compare to the current draft specification here? Those that do specify are *much* more obvious and simple in their comparison of individual components than what is currently in the ‘distutilsversion’ specification. Usually it's a simple case of “once we've got the individual components of a version string, they compare alphanumerically”.
I don't think alphanumeric comparison is what most would expect.
I think it's far more likely to be what someone would expect than any other *specific* arbitrary ordering of words that is chosen. You make this point yourself in the current draft: … it is much preferable if the versioning spec is such that a human can make a reasonable attempt at that sorting without having to run it against some code. What evidence is there that some arbitrary ordering of specific sets of words is going to be correctly guessed by such a person than a simple “alphanumeric ordering” specification?
For example if you use dates for your version, it'll work perfeclty with alphanumeric comparison but Fedora packagers will fail at sorting your versions properly.
I don't see how this is relevant. I'm not talking about removing the need for dividing a version string into separately-comparable components. That's clearly useful, and anyway is pretty uncontroversial and widespread. I'm arguing that, having got those components, and needing to compare them *within an individual component position* for ordering, the best candidate for “simple to describe and remember, and obvious to guess” is that the components are compared alphanumerically with no special exceptions. -- \ “An idea isn't responsible for the people who believe in it.” | `\ —Donald Robert Perry Marquis | _o__) | Ben Finney