[Distutils] Differences in PEP386 and setuptools

[Donald Stufft]

On Thursday, September 27, 2012 at 9:12 AM, Erik Bray wrote:
> My guess--and this is pure speculation as I wasn't following the
> original discussions either--is that it fell out of the desire to
> require versions to be lexicographically ordered. So "dev" would
> *have* to come after "a", "b", and "c" whether we like it or not. But
> at some point the convention to use ".dev" was proposed, which solves
> this issue--this puts it before "a" lexicographically and thus makes
> more sense in general. Although ".dev" made it into PEP 386 it seems
> the rest of the PEP wasn't changed to reflect the fact that ".dev" now
> comes first.
> 
> Again--just speculation. But I don't see any way that the PEP as
> written makes sense without assuming some kind of editorial oversight.
> 
If that's the reason (and I wasn't around during the original discussions) then
that's already been broken by rc/final (final is given an internal representation
of `z` to allow ordering to work. 

The way the PEP is written .devN is a pre-release of a specific version (a version
being a numbered release of either alpha, beta, candidate, or final). While I think
pre-releases of a specific version is likely useful in some context, I think that it
should be using an identifier more like `pre`. Using the `dev` tag to me violates
what a user expects from history.

I'm not discounting that there is a reason that makes sense though, hopefully if
there is one someone will be able to come forth with it. I personally feel though
that the current behavior is unexpected, will cause confusion as long as releases
are being ordered by both pkg_resources and PEP386, and goes against common
usage of the release tags. My proposal would be to replace the .devN pre-release
tag with .preN, and add a `devN` tag (perhaps optional N, with an omitted N being
equal to `dev0`. I feel like this will fit into people's expectations better, and make
migration easier.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120927/cf5fe507/attachment.html>