[Distutils] PEP 386 status - last round here ?

M.-A. Lemburg mal at egenix.com
Thu Dec 3 16:50:50 CET 2009

Tarek Ziadé wrote:
> On Thu, Dec 3, 2009 at 1:55 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>> Tarek Ziadé wrote:
>>> Last, as I said in a previous mail, I tend to agree with the people
>>> who said that we should stick with only one way to write the version
>>> scheme for the sake of clarity. e.g. dropping aliases and picking
>>> *one* way to write the markers after major.minor.micro.
>>> I would tend to pick the same scheme than Python for the pre-releases
>>> (and c + rc):
>>>     N.N[.N][(a|b|c|rc)N]
>>> And, for the post/dev markers I think dots are OK for readability,
>> Sure, but readability and clarity means different things for
>> different people.
>> The reason I proposed aliases and underscores is to give package
>> authors the choice of using terse forms or more verbose ones, as
>> well as making the whole scheme more compatible to existing
>> version strings already in use.
>> Regarding post/dev markers:
>> IMO, it's not really obvious that a 1.0a1.dev123 release refers to a
>> snaphost *before* the 1.0a1 release. The string "pre" is more commonly
>> used for such pre-release snapshots.
>> For the .post123 tag, I don't see a need for a "post" string at all,
>> 1.0a1.123 is clearly a release or build *after* the 1.0a1 release
>> and since the "1.123" is being treated as alpha version number,
>> the post part processing can be dropped altogether.
>> For the .dev part the situation is similar: you can always
>> choose a pre-release version that is not actually released and then
>> issue follow up snapshots to this, e.g.
>>        1.0a0.20091203
>>        1.0a0.20091204
>>        1.0a0.20091205
>> and so on for nightly builds during the development phase.
>> Instead of writing:
>>        1.0a1.dev20091205
>> you'd then write
>>        1.0a0.20091205
>> This is how Python itself is organizing the versions during
>> development, BTW.
> So IOW, are you suggesting that a suffix marker is always a post
> release marker ?

In a way, yes.

For pre-releases, it's actually a minor revision of the pre-release
version, e.g. in 1.0a0.123 the "0.123" part is the pre-release

For releases, it's a normal part of the version number, e.g.
in 1.0.123 the ".123" marks a patch level release.

> so we have :
> 1.0a0
> < 1.0a0.124
> < 1.0a0.245
> < 1.0a1
> < 1.0a1.346
> < 1.0a2
> < 1.0
> < 1.0.567  <--- dev marker

That's not a dev-marker, it's actually part of the release version:
the patch level release number.

> The problem in that case is that we would be unable to differenciate
> dev marker with micro markers.

The dev markers introduce an extra level of confusion, which
IMHO is not necessary.

Let's take 1.0a0.dev123 as example, reading it from the left:

1.0          - ok, so this is part of a 1.0 release
1.0a0        - oops, no, it's not actually part of a release, it's part
               of a pre-release, so move back
1.0a0.dev123 - hmm, not even that, it's part of what's going
               to become a pre-release, so move even further back

As developer you typically want to use the version number to
tell the user a few things about your package:

1. whether it's release quality code


2. whether it's a development snapshot


3. whether it's working code, but still under development


4. whether it fixes some bug that was found after a release


> That's why we added these "dev" markers in the first place. So
> following your ordering:
> - 1.0a0
> < 1.0a0.dev124
> < 1.0a0.dev245
> < 1.0a1
> < 1.0a1.dev346
> < 1.0a2
> < 1.0
> < 1.0.dev567  <--- dev marker
> Now about making the dev a post release tag, AFAIK people always use
> dev markers as pre-release tags:
> - 1.0a0
> < 1.0a1.dev124
> < 1.0a1.dev245
> < 1.0a1
> < 1.0a2.dev346
> < 1.0a2
> < 1.0.dev567  <--- dev marker
> < 1.0
> Last, if we want to do a post release for 1.0 for example, you would
> also need a post- marker, as we added

Sorry, I probably wasn't clear enough. What I proposed looks like this:

  1.0a0 (which is not released and only used to mark the start of 1.0
         development, just like we do for Python)
< 1.0a0.124
< 1.0a0.245
< 1.0a1     (pre-release)
< 1.0a1.346
< 1.0a2     (pre-release)
< 1.0       (release)
< 1.0.567   (release)

and the 1.0.567 is not a dev-marker (since the proposal is about
removing these ;-), but instead a post-marker without the
"post". In reality, such a post release would be a patch-level

If you want to then work on release 1.1, you'd continue with:

- 1.0.567
< 1.1a0 (which is not released and only used to mark the start of 1.1
         development, just like we do for Python)
< 1.1a0.124
< 1.1a0.245
< 1.1a1     (pre-release)
< 1.1a1.346
< 1.1a2     (pre-release)
< 1.1       (release)

As you can see, you don't need any dev-markers and post-markers
turn into pre-release minor version numbers... less noise,
more clarity, well at least IMHO.

Marc-Andre Lemburg

Professional Python Services directly from the Source  (#1, Dec 03 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611

More information about the Distutils-SIG mailing list