On Sat, Nov 28, 2009 at 12:28 PM, Floris Bruynooghe
On Fri, Nov 27, 2009 at 10:00:22PM -0500, P.J. Eby wrote:
This is why I've argued for keeping a scheme in 386 that can mechanically translate most existing versioning schemes found in the wild: it means that most people won't have to do a thing, as tool builders can just use suggest_version().
This is an important point. I tought the aim of PEP 386 was to create a version scheme that can represent every version number developers want to express, not to create one that allows everyones favourite syntax.
Absolutely, "suggest_rational_version" is just here to allow package managers softwares to handle existing versions, and eventually raise a warning when they get those.
And it seems most of the discussion has now ventured back into the syntax (flamewars/bikeshedding?) instead of whether everyone can express the versions they need to.
Agreed. We jumped again in the black hole :) I don't see much progress in the thread. Fact 0: This PEP is important for interoperability Fact 1: We do need to express development versions, post/pre release versions and we do want to have a standard to be shared among public python package installers. Fact 2: there are many ways to express those markers, but the PEP will document *one* way and promote its usage, so public package installers are all *compatible* (distutils, pip, etc..) Fact3: suggest_rational_ version will offer a tool for installers to deal with more version schemes, and it is suggested that it warns the developer that the scheme is not PEP 386 compliant. So If the current proposal works for all cases (e.g. people can translate their schemes into PEP 386 one), I am proposing to: 1- reject the "+", " ", "-" proposal, and stick with "." so we have only one way to express the segments. (ala Python itself) 2 - keep the aliases (alpha/beta/rc) because they are not controversial 3 - stick with "post" "dev" for the post and pre-release tags because *we need them to sort development versions and post versions* in installers, and because *they don't hurt* for people that are not publishing such versions. They will be able to use their own dev markers internally if they want. Next, once the PEP is edited, I am proposing to move this discussion in python-dev, for another round, and eventually have Guido accept it or reject it and move forward with PEP 345. Because as far as I am concerned, even if we change the syntax in PEP 386 a million times, some people will not like it at the end. regards Tarek