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

On Thu, Jan 08, 2004 at 04:24:56PM -0600, kfogel@collab.net wrote:
> Justin Erenkrantz <justin@erenkrantz.com> writes:
>...
> > 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.

Right.

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

No. Those guidelines are necessary to create some kind of sanity in the
upgrade/compatibility process.

There was a post today that said something like this (I'll respond to it
directly in a bit):

  "but if I upgrade SVN, then wouldn't I also have to upgrade all my
   clients? [similar to the case of upgrading a client necessitating an
   upgrade of svn]"

The answer is that upgrading SVN does *not* force an upgrade on the
clients. That is the whole reason for the design.

If you upgrade SVN from 1.0 to 1.7, then all applications will continue to
function properly. No need to update them. Any 1.x release provides all
the entry points, signatures, and semantics of the prior 1.x releases.

On the other hand, if you create an application that requires
functionality from 1.4, then you will need to update that SVN 1.1
installation to 1.4. But this is a safe thing to do, per above. That
upgrade will not break other applications.

> 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 disagree. :-)

Part of the problem here is the conflation of using the version number to
describe feature enhancements ("2.0 has a lot of wicked cool new
functionality") and binary compatibility ("2.0 has a few minor feature
enhancements, but the API was drastically revamped").

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org