On Fri, 2003-12-05 at 04:14, Greg Stein wrote:
> People are going to want to try the new features, and we are going to
> *want* them to try them out. This is going to be necessary *before* we
> create a 1.1 branch. Thus, I believe your assumptions above will not work
> out for us very well.
First, I don't agree. Very few projects need these kind of interim
releases. One very visible project (Linux) does, but if you look
broadly at open source projects, they generally don't.
Second, if you turn out to be right and we do want to do this, then I
think we can release "svn-snapshot-r8859.tar.gz". Other projects do
this from time to time. Binary packagers can either avoid packaging the
snapshots, or make svn-snapshot packages which conflict with svn
packages.
> I also prefer consistent triplets(*), and along that line, I dislike the
> 1.1.betaN format. The even/odd works well because we can do 1.1.0 thru
> 1.1.20, and then pop it to 1.2.0 for the stable release.
Well, then we have a decision to make. 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).
Incidentally, I'll note that Linux does not use pure numeric versions;
they go with odd middle numbers for unstable development but then when
they want to transition to a new even release, they come out with
versions like "2.6.0-test11" or "2.2.0-pre3" for a while.
In another message, Colin Watson said of my proposed scheme:
> It's not compatible with dpkg, though:
I'm told this is a cause of some amount of consternation in Debian,
leading to package version numbers like "1.2.99-1.3beta3", where 1.2.99
is a completely ficitious version number designed to sort correctly.
I'm also told that there has been some discussion of adding a version
character which sorts lower than any other character, such that
"1.1~beta1" would be less than "1.1", but I don't know the status of
that proposal.
A modification of the Berkeley DB scheme satisfies my constraints while
still guaranteeing correct sorting:
1.1.0-alpha
1.1.1-alpha
1.1.2-beta
1.1.3-beta
1.1.4
This is similar to Fitz's compromise except that instead of even-odd, we
release at 1.1.n (n>0) instead of bumping to an even middle version
number. I think I still prefer my previous proposal, dpkg issues
notwithstanding, but I'm willing to budge.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 5 18:35:17 2003