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.