Tarek Ziadé wrote:
On Thu, Dec 3, 2009 at 1:55 PM, M.-A. Lemburg <mal@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/