Re: API-changing releases was Re: concerns about issue #1682

--On Thursday, January 8, 2004 4:24 PM -0600 kfogel@collab.net wrote:

> about this. But I also think 2.0 is not too long to wait for such a
> change -- it doesn't have to be infinitely far in the future, if we
> feel there's a lot to change.

FWIW, I thought that the most aggressive estimates on dev@svn for a 2.0
were at least several years away...

> 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...

> I'd like to be able to release something soon (like, six months) after
> 1.0, that fixes API problems which were only discovered by virtue of
> 1.0 being out in the world. Would be nice to call that new thing
> "1.1" or "1.2", whereas "2.0" would imply huge new features (which
> wouldn't be the case).

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.

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.

> There's no reason why we can't discuss this while 1.0 stabilizes...

Sure. -- justin

---------------------------------------------------------------------
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:27:47 2004