[Distutils] Differences in PEP386 and setuptools

[Donald Stufft]

On Thursday, September 27, 2012 at 2:03 PM, Toshio Kuratomi wrote:

> That's your preference, not capability. I'd also say you should use
> 1.0.post1 rather than 1.0a1pre1.

So how do you encode the very first development release then if you're
using post? Can you point me towards somewhere where their conceptual
release cycle is

Final -> Dev -> Alpha -> Beta -> RC

or

Alpha -> Beta -> RC -> Final -> Dev

How can you release any sort of Alpha/Beta/RC/Final prior to having done
development? If Dev is a post release what do you call it before you've had
your first Alpha?
> 
> > On the surface 1.0a1.dev1 looks like it might be alright, but my issues with
> > it:
> > 
> > 1. It's not intuitive (at least not to me, development snapshots have
> > always come before alphas in my mind)
> > 
> 
> There's no such consensus. This is both from dealing with upstream
> versioning as a distro packager and from discussion with other people who
> worked on the versioning spec. People were very clear that they wanted to
> be able to stick dev versions in the middle of their attempt to release
> alphas, betas, rcs, and finals.
> 
> You can see this in current, setuptools-driven practice in the snapshots
> that pje hosts, for example:
> http://peak.telecommunity.com/snapshots/
> 
> 
> > 2. Goes against what is currently being used for either no good reason or
> > a yet to be remembered good reason.
> > 
> 
> 
> I've given you the reasons above. I'd also point out that with your
> clarification that you want .dev to be a toplevel alongside 'a', 'b', and
> 'c' you are also changing how dev is being used for no good reason -- simply
> to fit your personal use case.

I'm actually reverting it back to the current defacto standard of what setuptools does. 

However upon further examination I've figured out I believe what's caused the
mismatch between expectations here. Essentially pkg_resources does it both ways.
given the tags dev, a, b, c and an implicit f, it allows you to "nest" them.

So:

    0.1dev1 < 0.1a1 < 0.1b1 < 0.1c1 < 0.1

However it also allows you to add modifiers to these "top level" releases such as:

    0.1.dev < 0.1a1.dev1 < 0.1.a1 < 0.1.b1 < 0.1c1 < 0.1

This also makes sense to me in my particular use case, and it sounds like it
makes sense in yours? My main concern is that shifting 0.1dev1 from
sorting before alpha/beta/candidate to sorting after them is going to cause
headaches. So perhaps a better proposal would be to allow .dev at any
level (as it does currently), but dictate that .dev sorts first at whatever level
it occurs at (which is what setuptools does). This fixes my major problem of
getting bitten because setuptools and PEP386 treat "1.0dev1" differently while
still giving people the ability to do "1.0a1.dev1". The major drawback being
that you can't do a "dev/pre" release between an rc and a final, but as pkg_resources
doesn't currently allow for that I would think that isn't a huge concern? That might
solve the use case for both sides?
> 
> (Note: I assume rc1 is also in all of these examples and sorts between c and
> "final")

Yes essentially, I mean conceptually c and rc should sort the same but practicality
beats purity and what not.
> 
> -Toshio 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120927/66efda41/attachment.html>