[GiNaC-devel] Making new releases: libtool
Richard B. Kreckel
kreckel at ginac.de
Tue Sep 22 12:58:19 CEST 2009
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
Thank you! And please add this to the Libtool manual. This explanation
is so much easier to understand than the existing one.
Richard B. Kreckel
More information about the GiNaC-devel