On Thursday, September 27, 2012 at 7:15 PM, Toshio Kuratomi wrote:
Some organizations and projects use it one way and others the other way. And unlike alpha, beta, rc ordering which is both long established in the computing industry and based on the sorting of the greek alphabet, the choice with .dev is arbitrary. That's what makes this a bikeshed. Either way of doing this is going to confuse and upset some of the consumers and there's no solid reason to say that the upset people are "wrong". At best you can say that they're late to the party.
From PEP386 we have distutils's StrictVersion, LooseVersion and pkg_resources's
My biggest reason is that it changes what 0.1dev1 means based on if you use setuptools or pep386 and setuptools is the current defacto standard and by breaking that you break expectations that already exist in the wild. The way pep386 does it is different then the way things are now. If we fast forward into a world with both a pep386 compatible packaging toolbelt and setuptools we are going to end up with two different definitions of where a top level devN sorts. parse_version. Of the 3 parse_version is the only one that handles this sanely at all, (StrictVersion it errors out on, LooseVersion sorts alphabetically, so a < b < c < dev < rc). Moving forward with PEP386 as is will break existing assumptions (I've already encountered this with my local testing) and leaves us no way to tell if the author meant to order things ala PEP386, or ala pkg_resources. Moving back to the behavior by pkg_resources in this area leaves us with the "bikeshed" color that people already expect and will not leave us in a state where a valid set of versions in both systems parse to two different orders which keeps the status quo.