A lot of useful observations have been made in this thread. We should
reach a conclusion in the next week or so, since 0.35 branches today
and is released next Friday.
Below, I'll offer a new proposal that takes these observations into
account. But before I do, a couple of points:
Greg Hudson is right that
> We cannot reconcile "completely numeric versions" with "unstable
> versions must be explicitly marked as such." No compromise will
> satisfy both constraints. And I think once we've made a
> decision, there's no benefit in "compromising" (particularly
> since any compromise would violate the first constraint).
I think it's very important that unstable versions be clearly marked.
But we can do it fairly non-intrusively, by making the descriptive
word a prefix to the number instead of a suffix.
Also, many have commented that one problem with using words in a
release number is that you don't know whether the word is leading to
the current number, or the next number. E.g., is the series
"1.1.1-unstable", "1.1.2-unstable", and so on, leading to "1.2.0", or
to "1.1"?
In the scheme I'm about to propose, it would lead to 1.2.0, but the
important thing is, it doesn't matter if non-developers know the
number of the next release, as long as we meet one simple condition:
if a minor number ever appears with a modifying word, it never appears
*without* that word. If a plain "1.1" never exists, it can never be
downloaded.
On to the proposal:
Let's use "odd==unstable,even=stable" in the minor numbers, but with
an "unstable-" *prefix* on all the odd-numbered releases. That way,
users don't need to know about the even/odd thing. The unstable
releases will always be clearly marked as unstable.
For example, here is a series of releases in order:
[...]
subversion-unstable-1.1.1.tar.gz /* development release */
subversion-unstable-1.1.2.tar.gz /* development release */
subversion-unstable-1.1.3.tar.gz /* development release */
subversion-1.2.0.tar.gz /* stable release */
subversion-1.2.1.tar.gz /* bugfix to stable release */
subversion-unstable-1.3.0.tar.gz /* development release */
subversion-unstable-1.3.1.tar.gz /* development release */
subversion-unstable-1.3.2.tar.gz /* development release */
subversion-1.4.0.tar.gz /* stable release */
subversion-1.4.1.tar.gz /* bugfix to stable release */
subversion-1.4.2.tar.gz /* bugfix to stable release */
subversion-unstable-1.5.0.tar.gz /* development release */
[...]
(The unstable tarballs will unpack into directories named
"subversion-unstable-X.Y.Z/", of course.)
I think users are unlikely to get confused and think that "1.1.X"
might follow "unstable-1.1.X", but even if they did, they won't ever
be tempted to download such a tarball, because no release named just
"1.1.X" will ever be made. That whole line will always have the
"unstable-" prefix, until one day 1.2.0 appears.
With this scheme, anyone looking at a set of releases can tell
immediately
a) What the set's ordering is
b) Which ones are considered unstable
And as for developers, even if someone leaves off the "unstable" in a
bug report, *we* will know from looking at the number that they are
using an unstable release.
One objection that was raised agains "-unstable" as a suffix is that
non-numeric suffixes might make packaging more difficult. I'm not
sure how severe that problem is, but anyway it's probably less severe
when the word is a prefix. Also, we don't really want to optimize for
packaging of unstable releases, I would think.
Another proposal was to use revision numbers as a fourth component in
the release number. I don't like that because it's hard (in a deep
way) to choose a revision that corresponds exactly to the set of
changes we're releasing, especially when releasing from a branch. And
without a descriptive word, it's still not completely clear that the
release is unstable, so why bother?
This new system wouldn't kick in until after 1.0 is out, by the way.
While we're on the "1.0-stabilization" branch, we just continue to
release 0.36, 0.37, etc, as necessary. Everyone's used to that
system, and since we won't yet have made a "1.0" announcement, there's
no more danger of someone thinking the software is stable now than
there was a week ago, or a month ago.
Granted that there are as many different release numbering systems as
grains of sand in the sky or stars on the beach: if you can live with
this, please say so, and if you absolutely can't, please say why.
When we settle, I'll document it all in HACKING of course.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 12 22:55:41 2003