[Distutils] PEP 386 status - last round here ?
mal at egenix.com
Thu Dec 3 17:19:58 CET 2009
Tarek Ziadé wrote:
>> 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
> How do you explicitely know here that "1.0.1" is a final release ?
> it could be a dev snapshot of "1.0"
No, dev snapshots of 1.0 would be marked as:
> Unless you are suggesting that snapshots are always timestamps, but that's
> just one way to number snapshots.
Snapshots can use any number format they like - as long as
it's numeric, e.g. timestamps, subversion revision numbers, etc.
Not hq hex revisions, I'm afraid, unless there's a standard way
to express them as (monotone) numbers as well.
>> 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.
> I see your point but the problem I see is that you are unable to explicitely
> make a difference between development snapshots and final releases, because
> projects can use three levels for their final releases:
> MAJOR or MAJOR.MINOR or MAJOR.MINOR.MICRO
> so if snapshots are only numbers, they can't be explicitely differenciated.
> IOW: 1.0.10 can be two things here, if I get it right:
> - a snapshot release of 1.0
> - the 1.0.10 final release
> So end-users and packagers will not know if they deal with a final
> release or not.
A snapshot will always be a version of a pre-release, so
it's clear that you get a snapshot when looking at:
(the "a0" signals the pre-release status)
OTOH, versions without pre-release marker are always release
(with whatever meaning those added levels may have, e.g. could be
build numers, branch version numbers, etc.)
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