[Distutils] Differences in PEP386 and setuptools

Toshio Kuratomi a.badger at gmail.com
Fri Sep 28 01:15:17 CEST 2012


On Thu, Sep 27, 2012 at 05:00:56PM -0500, Brad Allen wrote:
> On Thu, Sep 27, 2012 at 2:45 PM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> 
> > 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 :-)
> 
> Why is this perceived as a bikeshed issue? It seems like a discussion
> about substantial functionality which is tied to the semantics of these
> special tags. For many projects and organizations, terms like 'alpha'
> and 'beta' and 'dev' have meaning in a release context, and rearranging
> the order of these concepts has an impact.
> 
dev has no universal defined relation to alpha, beta, etc in a release
context.

We all seem to be amenable to:

1.0alpha1.dev1  < 1.0alpha1

But people have not agreed whether:

1.0.dev1 < 1.0alpha1
or
1.0alpha1 < 1.0.dev1

Either of these cases can also be functionally replaced with the appropriate
.post tag:

1.0.dev1 < 1.0alpha1 ===>  0.9.post1 < 1.0alpha1

1.0alpha1 < 1.0.dev1 ===>  1.0alpha1 < 1.0rc1.post1

(Substitute the last "final" release for 0.9 in the above and substitute
whatever version you're snapshoting after for 1.0rc1)

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.

> > So to be clear my proposal would be:
> >
> >     1.0dev1 < 1.0a1 < 1.0b1 < 1.0c1 < 1.0.pre1 < 1.0 < 1.0.post1
> >
> > as opposed to the current:
> >
> >     1.0a1 < 1.0b1 < 1.0c1 < 1.0.dev1 < 1.0 < 1.0.post1
> >
> 
> +1 for the proposal to change the PEP so that 'dev' versions are
> earlier than 'a' versions.
>
Note, just in case my chart is misleading, the proposal doesn't change all
'dev' versions to be earlier than the 'a' versions.  '.dev' is a modifier.
So it can be applied to any of the toplevel portions of the version.

So to be more complete, the proposal is to do this::

0.1
  < 0.1.post1
  < 1.0.dev1        # The .dev that's changing position
  < 1.0a1.dev1
  < 1.0a1
  < 1.0a1.post1
  < 1.0b1.dev1
  < 1.0b1
  < 1.0b1.post1
  < 1.0c1.dev1
  < 1.0c1
  < 1.0c1.post1
                    # The current PEP386 position of 1.0.dev1
  < 1.0
  < 1.0.post1

-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/4a950297/attachment.pgp>


More information about the Distutils-SIG mailing list