[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guile versioning

From: rm
Subject: Re: Guile versioning
Date: Tue, 17 Jul 2001 19:34:25 +0200
User-agent: Mutt/1.0.1i

On Tue, Jul 17, 2001 at 12:03:50PM -0500, Rob Browning wrote:
> Martin Grabmueller <address@hidden> writes:
> > - Do we want to have the same library version numbers for all shared
> >   objects (guile-readline, srfi libs, qthreads)?
> That's a good question, but I tend to think that all of these things
> should be versioned separately in the long run unless we're going to
> go with the even simpler strategy of just bumping all of the library's
> CURRENT values and reseting their AGEs to 0 anytime we have to do it
> for any one of them.  

Is this really a working idea? Doesn't that mean that an application
linked against the library won't work with the new version _even if
the API didn't change at all_? As far as i understand the libtool
docs the version number describes API interoparability. There is
no reason to keep the library versions in sync. 

>                       This could get ugly, though if a change to
> srfi13 requires us to change the libqthreads and/or libguile major
> version numbers (i.e CURRENT).  This would also be untenable for
> modules with libs being maintained outside the guile main tree.
> I was planning to at least deal with the libguile CURRENT, REVISION,
> and AGE numbers for the stable branch soon, but I agree that it would
> be worth answering your questions first.
> (The fallback default (guaranteed safe, but possibly heavy-handed) is
>  to just do what I mentioned above, bump CURRENT and zero AGE for all
>  the libs which effectively gives them new major numbers...)

Which, following rhe libtool semantics, means that they changed their
API and aren't backward compatible at all.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]