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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
