I agree *completely* with Philippe here. If a version standard will be enforced what's the point of making it more complicated that a sequential number or something along x.y.z? In the end that's what the version number is. On Mon 04/02/13 16:31, "Philippe Ombredanne" pombredanne@nexb.com wrote:
On Mon, Feb 4, 2013 at 2:10 PM, Nick Coghlan
wrote: As usual, PEP inline below and on the web at http://www.python.org/dev/peps/pep-0426/ Version scheme ============== Version numbers must comply with the following scheme:: N.N[.N]+[{a|b|c|rc}N][.postN][.devN]
Version numbers which do not comply with this scheme are an error. Projects which wish to use non-compliant version numbers must restrict themselves
IMHO a version (or eventually its dot-separated segments with precedence from left to right) should increase when sorted lexicographically so it is never ambiguous for a human reading a list .... Are we trying to make a version -- which is an engineering must -- into something that has also some semantics about the level of completion of a project or some "marketing" alert on the level of maturity of a software release? Could we stay instead in the realm of engineering?
I think that trying to inject things like alpha, beta, post, dev, release candidates and the likes in this is trying to bake in too many things that are eventually just the practices of some projects and should not be the frozen practice baked in a PEP. Instead, this should be left to project authors to define their own scheme as long as it sorts lexicographically (eventually by segments, with precedence from left to right).
-- Philippe Ombredanne
+1 650 799 0949 | pombredanne@n exB.com DejaCode Enterprise at http://www.dejacode.com nexB Inc. at http://www.nexb.com
Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig