[..] > 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" Unless you are suggesting that snapshots are always timestamps, but that's just one way to number snapshots. [..] > 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. Regards Tarek _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
