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.
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.
From PEP386 we have distutils's StrictVersion, LooseVersion and pkg_resources's
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.