[CLN-list] Making new releases: libtool

Ralf Wildenhues Ralf.Wildenhues at gmx.de
Mon Sep 21 19:57:48 CEST 2009


Hi Richard,

* Richard B. Kreckel wrote on Sun, Sep 20, 2009 at 10:28:25PM CEST:
> I just figured I would like to make a new release of CLN. I then
> realized that setting version numbers has always been confusing me.
> Until now, I've never cared as much about this as I should, but this
> should some day get clarified.
> 
> The configure.ac file in CLN says:
[ pretty much a copy of 'info Libtool "Updating version info"' ]

> dnl * increment CL_REVISION,
> 
> dnl * if any functions/classes have been added, removed or changed,
> dnl   increment CL_CURRENT and set CL_REVISION to 0,
> 
> dnl * if any functions/classes have been added, increment CL_AGE,
> 
> dnl * if backwards compatibility has been broken, set CL_AGE to 0.

OK so far.
 
> dnl $(CL_CURRENT):$(CL_REVISION):$(CL_AGE) results in
> 
> dnl libcln.so.$(CL_CURRENT)-$(CL_AGE)

This is not necessarily true.  It only holds on some systems, but not on
all.

> Okay, let's see. I've fixed a function that used to segfault and
> I've added support for a platform that was not supported before. I
> increment CL_REVISION.

OK.

> Have I added, removed ro changed a function
> or class? I'm not sure. Interface-wise not. But I've changed
> functionality (it doesn't crash any more). So I increment CL_CURRENT
> to 7 and set CL_REVISION to 0.

Why?  I'd only do that if the crash was part of previously documented
behavior, i.e., intentional, and that users of the old version of your
library rely on it crashing, and need to change their code and
recompile/relink to use the new version.  If all you've done is a bugfix
then I don't see why your interface has changed.  So all you do from the
previous release is bump up CL_REVISION, and not touch the rest.

The whole thing is pretty simple if you consider that there are three
possible kinds of reactions from your users to changes from you:

1) Programs using the previous version may use the new version as
drop-in and programs using the new version can also work with the
previous one.  IOW, no recompiling, no relinking needed.  In this case,
bump REVISION only.

2) Programs using the previous version may use the new version as
drop-in but Programs using the new version may use APIs not present in
the previous one.  IOW, a program linking against the new version may
fail with "unresolved symbols" if linking against the old version at
runtime: REVISION = 0, bump CURRENT and AGE.

3) Programs may need to be changed, recompiled, relinked in order to use
the new version.  REVISION = 0, bump CURRENT, AGE = 0.

HTH.  We should probably add something like that to the Libtool manual,
but for that I should think about this a bit more, in case I overlooked
something.

Cheers,
Ralf


More information about the CLN-list mailing list