On Mon, Feb 4, 2013 at 2:10 PM, Nick Coghlan <ncogh...@gmail.com> 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 > to metadata v1.1 (PEP 314) or earlier, as those versions do not mandate > a particular versioning scheme. > > Suffixes and ordering > --------------------- > The following suffixes are the only ones allowed at the given level of the > version hierarchy and they are ordered as listed. > Within a numeric release (``1.0``, ``2.7.3``):: > .devN, aN, bN, cN, rcN, <no suffix>, .postN
Are we trying to mix in too many thing in a versioning scheme? 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 of versioned components, sorts naturally in most filesystems and tools and is easy to implement. With the proposed scheme, I can picture myself having to call some code each time I need compare two package versions and scratching my head otherwise. Having been involved in defining version schemes in the past for Eclipse, I came then to the conclusion that anything that does not sort lexicographically is probably a bad idea. 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 | pombreda...@nexb.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
