Re: Guile versioning

[Rob Browning]

Martin Grabmueller <address@hidden> writes:

> - Should the library versions be incremented to?

Since we are using libtool, we should be following the guidelines
found in the libtool info chapter "Library interface versions".  They
do a very good job of explaining their versioning system and how we're
supposed to use it.

I suspect that for this release, we'll be all the way up to having to
set AGE to 0 as required in step 6 on the libtool "Updating library
version information" info page, but in general, we should follow those
steps.

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

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD