[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Naming of function versions

From: Greg Stein <gstein_at_lyra.org>
Date: 2004-03-18 02:50:26 CET

On Wed, Mar 17, 2004 at 06:31:55AM +0200, Nuutti Kotivuori wrote:
> kfogel@collab.net wrote:
> > Nuutti Kotivuori <naked@iki.fi> writes:
>
> [...]
>

[ in reference to "avoid 1.1 functions so your code works against 1.0" ]

> > I think if we use your interpretation, the burden on development is
> > simply too great. We've been very clear about what's guaranteed and
> > what's not; let's not impose more burden on ourselves for the sake
> > of an entirely avoidable use case.

It isn't "simply too great". It just isn't possible. If you compile
against 1.1.x, then your application *requires* 1.1.x. There isn't
anything that you can do unless you lift the hood and dig very very hard
to ensure that your app can bind/work against 1.0.x.

The simplest example is a #define constant changing from 1.0.x to 1.1.x.
That changing value can then make a particular function alter its
behavior. It would know whether a 1.0.x or a 1.1.x user is calling it.
This kind of change in the constant is acceptable under the guidelines.

Something built against 1.0.x must continue to function with the 1.1.x
libraries (and the guidelines are defined to enable this), but the reverse
does not hold true. If you install a 1.1.x application, then the libraries
must be upgraded to 1.1.x. The theory here is that an administrator can
feel safe doing the upgrade because it will not break any existing 1.0.x
applications.

>...
> > Sure! We should continue using "@deprecated", because it gives us a
> > well-defined string to search for. But there's no reason the
> > additional documentation can't be present. It can only help. That

Agreed.

> > way if someone *wants* to write compatibly with the 1.0.x API, they
> > can do so, even if only 1.1.x is present on their system.

With the caveats mentioned above. Whatever you compile against will
determine what you must link/run against. If you code to the 1.0.x API and
build against it, then you can run on a system which has 1.x.y libraries
installed.

> On that note, we should probably start using "@since 1.1" (or 1.1.0,
> if that is preferred) on every new function (or thing) added to the
> interface - and probably nuke all those tags at 2.0, since it won't
> matter then anymore and it is just clutter.

Absolutely agreed. ++1.

>...
> > P.S. I've held off putting anything in HACKING about this until the
> > thread reaches some sort of obvious consensus :-).
>
> Well, I still consider the approach here unconventional, but by no
> means unsound. So as long as it is documented, it's all rose petals
> and vanilla ice-cream.

Unconventional? What aspect? I must have missed an earlier post of yours :-)

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
Received on Thu Mar 18 02:52:25 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.