[GiNaC-devel] Making new releases: libtool

Richard B. Kreckel kreckel at ginac.de
Tue Sep 22 12:58:19 CEST 2009


Hi Ralf!

Ralf Wildenhues wrote:
>> 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.

I find the phrase "functions/classes have been changed" rather 
confusing. It is unclear what "changed" means.

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

Thank you! And please add this to the Libtool manual. This explanation 
is so much easier to understand than the existing one.

Cheers
   -richy.
-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>


More information about the GiNaC-devel mailing list