[Distutils] Differences in PEP386 and setuptools

[Toshio Kuratomi]

On Thu, Sep 27, 2012 at 01:00:10PM -0400, Donald Stufft wrote:
> On Thursday, September 27, 2012 at 11:59 AM, Toshio Kuratomi wrote:
> 
>     I would be for renaming .dev to .pre[1]_ but I would be against the rest of
>     this
>     proposal. Having one and only one way to spell things was one of the goals
>     of the pep. Having two post release tags that don't already have a defined
>     meaning leads to confusion about what the ordering should be:
> 
> dev (in my proposal, and in the way I've seen it used) isn't a post release
> tag,
> it is a separate release at the same level as alpha, beta, rc, final, and it's
> meaning tends to be "this is the in development version of what will become
> release X.Y", so foo-1.0dev1 means the first development release of what
> will become foo-1.0, (just like foo-1.0a1 is the first alpha release of what
> will become foo-1.0).
> 
> With the current layout (and with your changes to the proposal) there is no
> good way to have a development version. With the current layout the best
> approximation you can get is 1.0a1.dev1 (similarly with your changes it would
> be 1.0a1.pre1).
> 
That's your preference, not capability.  I'd also say you should use
1.0.post1 rather than 1.0a1pre1.

> 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.

>     3. Requires you to decide ahead of time if you're going to go from dev
>         to alpha, or straight to a beta/candidate/final. (This is something
> that
>         most small projects don't have set in stone).

Really?

Today I release:
   1.0a1.dev2012

Tomorrow I release:
   1.0b1

The versions sort.  There was no forethought needed.  Now if I was to do
this, I'd use:
   1.0.post2012

as my first release instead.


>      4. It's semantics are different, this is a development release of
>          1.0a1 as opposed to a development release of the 1.0 version.

Correct.  And "this is a development release of 1.0a1" is what people that
designed the version specification wnated.  The "development release of the
1.0 version" case is taken care of by .post.

>      5. It's just plain ugly.
> 
I'd say the same thing about 'a', 'b', 'c' vs 'alpha', 'beta', 'rc'; .post
and .pre, etc.  Ugly seems to be the path to painting bikesheds.

> 
> So to be clear my proposal would be:
> 
>     1.0dev1 < 1.0a1 < 1.0b1 < 1.0c1 < 1.0.pre1 < 1.0 < 1.0.post1

So is your proposal to get rid of all modifiers?  ie: there will be
toplevels that sort at the same level as the alpha/beta/rc tags?  If so, I'd
get rid of the pre tag in there and rename dev to pre as dev means "post" to
some people and "pre" to others.  I'd also remove the "." since they're all
at the same level:

1.0pre1 < 1.0a1 < 1.0b1 < 1.0c1 < 1.0 < 1.0post1

While I'd be for this, this was definitely counter to the desires of a good
number of the other people who participated.  They definitely wanted
modifiers to denote that a snapshot dev instance applied before or after an
alpha/beta/rc.

If you do intend to keep .pre and .post as modifiers, I would be against
adding dev as a toplevel.  it's just adding another name with no clear
definition in the collective minds of the people consuming the versions
where the functionality is already provided for by the .post and .pre
(current .dev)

> as opposed to the current:
> 
>     1.0a1 < 1.0b1 < 1.0c1 < 1.0.dev1 < 1.0 < 1.0.post1


(Note: I assume rc1 is also in all of these examples and sorts between c and
"final")

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