[Dev] Milestone numbering going forward

[Phillip J. Eby]

At 09:05 AM 11/30/2005 -0800, Alec Flett wrote:
>Aparna Kadakia wrote:
>>[Aparna]: The forward numbering scheme does indeed solve this problem 
>>because the trunk would be numbered 0.7 onwards whereas the branch 
>>releases will continue as 0.6.01, 0.6.02 etc. This would be lot less 
>>confusing than having trunk on versions like 0.6.01 and the branch on 0.6.0.1
>I have to agree with heikki here - when 0.7 goes out the door its just 
>going to get confusing again. because we'll have 0.7.m1 and 0.7.1 and 
>they'll be very different builds. And what do we call the intermediate 
>builds after 0.7 and leading up to 0.7.1? "0.7.1.m1"?  Its confusing 
>either way. All we've done is delayed our confusion from the beginning of 
>the 0.7 milestone to the end of the milestone, when we'll have to have 
>this debate again.
>
>So here's my vote on this:
>1) if we go with a backwards numbering system, then we use "M" - 0.6m1, 
>0.6m2, ... 0.7. This allows us to release a 0.6.1 (lets say, 
>hypothetically for PyCon 2006 we might need to tweak the branch for some 
>development work..)
>2) if we go with a forwards numbering system, then we use "alpha" or 
>something to indicate that we're leading up to the release - 0.7alpha1, 
>0.7alpha2,...0.7.
>
>In either of these schemes, I would love to also see subversion revision 
>numbers (r8403) added to the version.. (0.6m1-r8403 or 0.7alpha1-r8403)

Just to be clear, are you intending the subversion revision to be a 
prerelease tag or a postrelease tag?  That is, is 0.7alpha1-r8403 *before* 
0.7a1 or *after* it?  If it's *before*, then I would suggest 
0.7a1.dev-r8403 to indicate that it is a version of 0.7a1 that is still 
under development, rather than a post-release patch.

Sorry to be so picky, but at this point I've spent quite a lot of time 
working on getting machine-readable version numbers to work well in the 
field with Python eggs, and I've found that the issue isn't so much coding 
the scheme, as getting people to be clear and consistent about what their 
version numbers mean in the first place!  I originally thought that simply 
codifying the most popular practices (a/b/c/rc/pl/pre/-/etc.) in use would 
do the trick, but it turns out that people are subtly inconsistent in ways 
that no parser can hope to match.  :(

Anyway, my initial survey showed that the most popular versioning schemes 
among Python packages and system packages showed that there were certain 
strings used to denote pre-releases (a, alpha, b, beta, c, candidate, rc, 
pre, and dev), and post-releases such as "ports" and "patch levels" (-, pl, 
p).  There were also rare systems that used sequential letters for patch 
levels, starting with 'a' and going up to 'z' if necessary.

So, for eggs, I created a syntax that "understands" these conventions to 
allow you to specify an arbitrary combination of pre- and post-release tags 
to describe exactly what you want.  In that scheme, 0.7a1.dev-r8403 is the 
r8403 postrelease of an in-development prerelease of the first alpha 
prerelease of 0.7.  By contrast, 0.7a1-r8403 is the r8403 postrelease of 
the first alpha prerelease of 0.7; a very different idea.

This scheme is infinitely flexible, in that it allows you to say whatever 
you want as long as you know what you mean to say.  Unfortunately, the 
tricky bit is that people have rarely thought it through to that level of 
detail, and I didn't even come up with the pre/post terminology until some 
egg users ran into problems with some corner cases of their version 
numbering and I realized that I needed to make the concept more explicit.

I don't really have an opinion on what Chandler's versioning scheme should 
be, but once it is decided upon, I would like to suggest that we "spell" it 
using setuptools' pre/post syntax features, so that our Python eggs in 0.7 
will be able to use the numbering.  For example, if we want to number 
releases moving *towards* 0.7 in milestones, then we should be using a 
prerelease tag between 0.7 and the m1, e.g. 0.7dev.m1 or 0.7a.m1, etc.

In other words, I am not proposing a particular versioning scheme, but only 
requesting that we *encode* it in a way that allows setuptools to 
unambiguously determine what we mean by a particular version, and thereby 
determine what versions are newer or older than others by knowing 
prereleases from postreleases and vice versa.