[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
version.
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
1.0.0
2. whether it's a development snapshot
1.0.0a0.20091202
3. whether it's working code, but still under development
1.0.0a1
4. whether it fixes some bug that was found after a release
1.0.1
> 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
release.
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
eGenix.com
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
http://www.egenix.com/company/contact/
More information about the Distutils-SIG
mailing list