Re: Guile versioning

[rm]

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.

 Ralf