On Sat, Nov 28, 2009 at 12:32 AM, Ben Finney <[email protected]> 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. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
