Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 14 Jun 2002 13:11:06 -0700
From: Greg Stein <gstein@lyra.org>
To: Philip Martin <philip@codematters.co.uk>, dev@subversion.tigris.org
Cc: dev@apr.apache.org
Subject: versioning (was: svn commit: rev 2201 - trunk trunk/build)
Message-ID: <20020614131106.J26765@lyra.org>
Mail-Followup-To: Philip Martin <philip@codematters.co.uk>,
	dev@subversion.tigris.org, dev@apr.apache.org
References: <200206140017.g5E0Hsp01932@svn.collab.net>
 <87y9di6mhp.fsf@codematters.co.uk> <87fzzp7oxy.fsf@codematters.co.uk>
 <87bsad7lut.fsf@codematters.co.uk> <20020614120726.A26765@lyra.org>
 <87znxx64xz.fsf@codematters.co.uk> <86u1o5psot.fsf@kepler.ch.collab.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <86u1o5psot.fsf@kepler.ch.collab.net>;
 from sussman@collab.net on Fri, Jun 14, 2002 at 02:26:58PM -0500

On Fri, Jun 14, 2002 at 02:26:58PM -0500, Ben Collins-Sussman wrote:
> Philip Martin <philip@codematters.co.uk> writes:
>...
> > On a related note, what does adding a version number to the library
> > name give us that we don't get from the normal shared library version
> > number?
> 
> Philip, read this document.  It's actually really good:
> 
>    http://www106.pair.com/rhp/parallel.html
> 
> To quote from this article:
> 
>   "Library sonames only address the problem of runtime linking
>   previously-compiled applications. They don't address the issue of
>   compiling applications that require a previous version, and they
>   don't address anything other than libraries."

As a case in point, consider our use of Berkeley DB. On my system, some apps
link against db-3.2 and some against db-4. It all works out quite well :-)
The basic problem is that you link against foo.so, rather than foo.so.1 or
foo.so.2. In this model, you link against foo-1.so or foo-2.so.

Note that we only need -1 or -2 or whatever. Per the rules specified in our
versioning document(*) (well, APR's, but we use it), we only change APIs at
major version number changes.

Hmm. Maybe that isn't quite right. If somebody builds against 1.2, they
cannot link against 1.1 (although the reverse is true). The issue is that we
want apps built against 1.1 to be usable against 1.2, 1.3, etc. But if they
link against libsvn_fs-1.1, then they won't get the newer libraries.

Well, heck. I'm of a mind to say that the minor version new vs old should be
handled by package dependencies. If you use a (new) function from 1.2, then
set your dep to be >= 1.2 and link against -1. Worst case (for systems
without deps) is that an error will pop from the runtime link loader.
"upgrade your lib"

This does make me think that we need a bit more rigor in the versioning. We
shouldn't use #define to map old APIs into new APIs. Otherwise, somebody
could end up using a newer API without realizing it. If they list their
package dep as >= 1.0 since they think, "I'm not using any APIs other than
what is 1.0", but their system has 1.4 and it remaps some functions, then
their package dep is wrong.

I'm going to go fix up the versioning document now...

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/