On Thu, Dec 03, 2009 at 01:55:53PM +0100, M.-A. Lemburg 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.
I'm not a big fan of underscores -- having multiple separators doesn't seem very useful. I don'tlike aliases but seeing as I like the long forms, having both short and long but giving them a distinct ordering would be okay to me (ie: a1 < alpha1 < a2 < b1 < beta1 < c1 < rc1
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.
FWIW, I agree with all of this section. -Toshio