GNOME Bugzilla – Bug 477709
Use libtool versioning info
Last modified: 2013-04-06 14:54:54 UTC
here's a small patch for generating and using the versioning information for libtool from the gtksourceview version. the patch requires that each time the API changes (additions, removals, changes), the gtksourceview_interface_age is reset to 0, while for every release that doesn't change the API, the number is increased by one. everything else needed by libtool is generated by m4 macros and from the gtksourceview version numbers. the patch also removes AM_MAINTAINER_MODE which doesn't do what the name implies and should never be used in any project: http://www.mcs.vuw.ac.nz/cgi-bin/info2www?(automake)maintainer-mode http://www.ecos.sourceware.org/ml/automake/2002-04/msg00094.html and friends (really: just search AM_MAINTAINER_MODE on google and you'll see what I mean).
Created attachment 95718 [details] [review] Use macros to derive the libtool -version-info argument
Created attachment 239579 [details] [review] Add Libtool versioning
The normal algorithm for updating the Libtool -version-info is not really complicated. The advantage is that smaller numbers are used. Since -version-info was not used, it was the version 0:0:0. The algorithm has been applied to the current situation (ABI break), see bug #696412.
Review of attachment 239579 [details] [review]: Looks good to me but you need approval from the release team, so ask for permission.
> # For development releases, keep the same numbers. It seems that for dev releases the numbers are also updated, except for REVISION which is set to 0. But the reason remains unclear to me, the documentation doesn't explain what to do for development releases. Maybe it's better to update the numbers wrt the previous _stable_ version, I don't know.
Approved: https://mail.gnome.org/archives/release-team/2013-March/msg00226.html
good lord, I forgot about this patch. (In reply to comment #5) > > # For development releases, keep the same numbers. > > It seems that for dev releases the numbers are also updated, except for > REVISION which is set to 0. But the reason remains unclear to me, the > documentation doesn't explain what to do for development releases. > > Maybe it's better to update the numbers wrt the previous _stable_ version, I > don't know. for what it's worth, this is the documentation I use for the same pattern in Clutter: # • for stable releases: increase the interface age by 1 for each release; # if the API changes, set to 0. interface_age and binary_age are used to # create the soname of the shared object: # # (<minor> * 100 + <micro>) - <interface_age> # # this allows using the same soname for different micro-releases in case # no API was added or deprecated. for instance: # # clutter 1.2.0 -> 100 * 2 + 0 = 200, interface age = 0 -> 200 # clutter 1.2.2 -> 100 * 2 + 2 = 202, interface age = 2 -> 200 # clutter 1.2.4 -> 100 * 2 + 4 = 204, interface age = 4 -> 200 # [ API addition, deprecation ] # clutter 1.2.6 -> 100 * 2 + 6 = 206, interface age = 0 -> 206 # clutter 1.2.8 -> 100 * 2 + 8 = 208, interface age = 2 -> 206 # clutter 1.2.10 -> 100 * 2 + 10 = 210, interface age = 4 -> 206 # ... # # • for development releases: keep clutter_interface_age to 0 m4_define([clutter_interface_age], [0]) though, strictly speaking, we only allow API addition and deprecation during development cycles, so the interface_age value should monotonically increase during stable cycles.
For development releases, I finally think it's better to keep the same -version-info. If a public function is added, a dev release is made, and then the function is renamed before the stable version, if the -version-info is updated for each dev release, we end up with a soname version bump for the next stable release, although from the point of view of stable releases, only one function was added. Anyway there was no -version-info for years, so it's not really a problem to not update it for dev releases.
*** Bug 697398 has been marked as a duplicate of this bug. ***