Tarek Ziadé wrote:
[..]
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
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: 1.0.0a0.123
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: 1.0.0a0.123 (the "a0" signals the pre-release status) OTOH, versions without pre-release marker are always release versions, e.g. 1.0.0 1.0.0.123 1.0.0.123.0.456 (with whatever meaning those added levels may have, e.g. could be build numers, branch version numbers, etc.) -- 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/