Re: library versioning

[John W. Eaton]

On 10-Dec-2011, Rik wrote:

| On 12/09/2011 10:00 AM, address@hidden wrote:
| > Should we keep libcruft, liboctave, and liboctinterp versions
| > synchronized, or should we handle them individually and only
| > update them if necessary?  For example, looking at diffs between
| > the current sources and 3.4.3, libcruft did not change, so we
| > would not have to increment its version number unless we want to
| > keep it in sync with the others that we do update.
| >
| > Reading the guidelines here
| >
| >   
http://www.gnu.org/s/libtool/manual/html_node/Updating-version-info.html#Updating-version-info
| >
| > it looks like the minimum changes in version numbers would be
| >
| >   libcruft:     0.0.0 -> 0.0.0
| >   liboctave:    0.0.0 -> 1.0.0
| >   liboctinterp: 0.0.0 -> 1.0.0
| >
| > For the future, I would consider merging the three libraries into one,
| > but with debugging symbols, that would generate a 325MB file on my
| > system.  That seems quite large, especially when we have to generate
| > it often.  I think it helps to keep it in separate chunks.
| >
| > Comments?
| Wouldn't it be easier from the user perspective if they were versioned
| identically?  I'm imagining running mkoctfile and having to check the
| versioning of 3 libraries versus only checking 1 version number.  Are there
| actual situations where users might only link against one of the three
| libraries, or is it pretty much all or nothing?

As I understand it, the version numbers are only used for the system
to determine whether it is OK to dynamically link a program with the
library.  Users should not need to know about the version numbers.
They should only be linking with -loctinterp -loctave -lcruft and
mkoctfile should not be checking version numbers either.

jwe