Justin Erenkrantz <justin@erenkrantz.com> writes:
> FWIW, I thought that the most aggressive estimates on dev@svn for a
> 2.0 were at least several years away...
There hasn't been any consensus on it, AFAICT..
> > http://apr.apache.org/versioning.html are maybe a bit too strict? I
> > feel like I want to move everything down one notch: major version
> > number change means major new features; minor version means same basic
> > features, but possible API changes; patch level means bug fixes and
> > small stuff.
>
> I think that's only reshuffling the deck chairs...
Well, not quite.
The current release number system forces us to use major version
increments for API changes. Unfortunately, the world at large assumes
that a major version increment also means major new functionality. In
other words, we have no way to introduce an API change without also
either introducing major new features, or disappointing users who
expect "more" from a 2.0.
It seems to me like we have four concepts conflated in three numbers:
a. Major feature additions
b. API changes
c. Changes that break binary compat
d. Changes that maintain binary compat.
Currently, (a) and (b) live in one number, the major version, and the
others have their own numbers. My reshuffling gives (a) and (b) each
their own number, and puts (c) and (d) in one number, the patch
level.
Another solution is to just have four numbers?
> I don't disagree, but the binary contract means a lot to us - perhaps
> there's a disconnect on whether we should even have binary compat
> rules? That might explain why there's been frustration on a bunch of
> proposed API changes. There are those of us (incl. myself) who realize
> that any warts in the API can't *really* be fixed if they make it into
> 1.0.
Oh, I realize it too. That's why I'm beginning to think that it's our
contract that's the problem...
> I'd personally also have no problem with running through major version
> numbers at a higher rate than previously suggested. But, that's been
> shouted down a number of times, I think.
I couldn't tell -- didn't feel a consensus on it, but hey, maybe I
missed something :).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 9 00:42:47 2004