[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