On Mon, Feb 4, 2013 at 10:31 AM, Philippe Ombredanne <pombreda...@nexb.com>wrote:
> 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) It's weird, but we need to maintain sort order with https://bitbucket.org/tarek/distribute/src/tip/pkg_resources.py?at=default#cl-1948for the subset of version numbers that fit the new regex. This issue has been discussed at length.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
