On Fri, Jun 5, 2009 at 3:55 PM, Ben Finney
Tarek Ziadé
writes: 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?
This is very upsetting ! This specification is not something I just pulled out of my hat. We worked during two evenings during Pycon with people from Fedora and Ubuntu on that (Toshio and Matthias Klose). Those people are packaging Python projects for their systems and have problems because of the lack of proper versioning sometimes. We were like +10 people the first night brainstorming on that topic. The proposal is something that everyone agreed was "good enough" there for packagers to work with. The only complexity we (I in fact) added later is the use case Philip brought up for the post-releases, and this something we are currently discussing in details in the ML/ But with your "N.N[.X]+" proposal, you are missing some things this PEP tries to adress, such as dealing with alpha, beta and candidate, or development versions.
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.
The RationalVersion class takes your string and split it in several components, does a bit of processing, and then compare the components alphanumerically. But there are extra rules for some of those components, (like alpha/beta/candidate restriction)