[Distutils] Differences in PEP386 and setuptools

[Toshio Kuratomi]

On Thu, Sep 27, 2012 at 02:42:50PM -0400, Donald Stufft wrote:
> 
> 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?

Took me a couple readings but I think you mean:

I start a project this morning.
I make a snapshot this afternoon.

What should the version be?

Using the current versioning scheme, I'd personally do:
0.dev1

By the time I get to an alpha release, we're going to have a version number
(for instance, 0.1).  So an initial version on the first day of 0 is fine:

0.dev1 < 0.1a1 < [...] < 0.1

/me has seen this in the wild as well... not just in my theoretical mind :-)

> Can you point me towards somewhere where their conceptual
> release cycle is
> 
> Final -> Dev -> Alpha -> Beta -> RC
> 
> or
> 
> Alpha -> Beta -> RC -> Final -> Dev
> 
I'm not sure what you're asking here.  All projects change code and release
it.  The changes may get released as something "official"-y like an alpha,
a beta, an rc, or a final.  They may also be released like a snapshot.
Those snapshots can be taken from any point on the timeline against any
release.  Trying to say that "snapshots only happen before alpha beta rc" or
"snapshots only happen after alpha beta rc" doesn't map to what people in
the real world are doing.

I think we both get to this same place down below, though, so I'll skip down
to there.


> 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?
> 
If we're just changing the position of X.Y.preN from this:

0.1 < 0.1.post1 < 0.2a1.pre1 < 0.2a1 < 0.2a1.post1 < 0.2b1 < 0.2pre1 < 0.2

to this:

0.1 < 0.1.post1 < 0.2pre1 < 0.2a1.pre1 < 0.2a1 < 0.2a1.post1 < 0.2b1 < 0.2

then that works perfectly fine for me.  To put out a snapshot between rc and
final, I'd do 0.2rc1.post1 so not having a pre/dev in there doesn't bother
me.

However, now that you mention it, ISTR that this is the way that it was
originally and the lack of pre/dev in that position did bother another (set
of?) the PEP authors enough that it was changed.  For me, switching the
search order of that particular piece is a bikeshed so I seem to have
reallocated the memory for storing the arguments made in favor of shifting
it to the current position :-)

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120927/e42811d2/attachment.pgp>