Re: [GiNaC-devel] Making new releases: libtool
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/>
Hi! After Ralf's tutoring I propose this patch to GiNaC's configure.ac: @@ -12,10 +12,11 @@ dnl version number. In particular, library version is OS dependent. dnl dnl When making releases, do dnl 1. Increment ginac_lt_revision -dnl 2. If any interfaces have been added, removed, or changed since the last -dnl release, increment ginac_lt_current and set ginac_lt_revision to 0. -dnl 3. If any interfaces have been removed since the last release, set -dnl ginac_lt_age to 0. +dnl 2. If any interfaces have been added since the last release, increment +dnl ginac_lt_current and set ginac_lt_revision to 0. +dnl 3. If any interfaces have been changed or removed since the last release, +dnl make sure you increment ginac_minor_version above and reset both +dnl ginac_lt_current and ginac_lt_revision to 0. dnl dnl Please note: the libtool naming scheme cannot guarantee that on all dnl systems, the numbering is consecutive. It only guarantees that it is @@ -23,7 +24,6 @@ dnl increasing. This doesn't matter, though: there is not incurred cost dnl for numbers that are omitted, except for shrinking the available space dnl of leftover numbers. Not something we need to worry about yet. ;-) m4_define([ginac_lt_current], [0]) -m4_define([ginac_lt_age], [0]) m4_define([ginac_lt_revision], [0]) AC_INIT([GiNaC], ginac_version, [<ginac-list@ginac.de>]) @@ -57,8 +57,9 @@ AC_SUBST(ARCHIVE_AGE) AC_DEFINE_UNQUOTED(ARCHIVE_VERSION, $ARCHIVE_VERSION, [Current GiNaC archive file version number]) AC_DEFINE_UNQUOTED(ARCHIVE_AGE, $ARCHIVE_AGE, [GiNaC archive file version age]) -dnl libtool versioning -LT_VERSION_INFO="ginac_lt_current:ginac_lt_revision:ginac_lt_age" +dnl libtool versioning (We don't use libtool's age numbering since we promise +dnl to keep the binary interface compatible if only ginac_micro_version changes.) +LT_VERSION_INFO="ginac_lt_current:ginac_lt_revision:0" LT_RELEASE="ginac_release" AC_SUBST(LT_VERSION_INFO) Unless somebody objects, I'm going to commit this. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
participants (1)
-
Richard B. Kreckel