Justin Erenkrantz <justin@erenkrantz.com> writes:
> > If you believe (as I do) that we are *bound* to discover more API
> > issues after we release 1.0 anyway, and that they will necessitate an
> > API-changing release sooner rather than later anyway, then this patch
> > should be left out of 1.0.
>
> Once we hit 1.0, you can't change any existing API prototypes until 2.0.
>
> So, say, if we change our parameters to svn_client_blame, we have to
> have the old version as svn_client_blame and the new entry point as
> svn_client_blame2 (or something like that to make the names different).
Yah.
We could anticipatorily rename svn_client_blame right now, to
svn_client_simple_blame() or whatever, if we really felt strongly
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.
> Just want to make sure we're all on the same page here... -- justin
Yes. I was just over at http://apr.apache.org/versioning.html
checking on this.
Am I the only one who is beginning to feel that the requirements at
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'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).
There's no reason why we can't discuss this while 1.0 stabilizes...
---------------------------------------------------------------------
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:19:22 2004