Re: Release management: how do you update the libtool version information?

[Simon Josefsson]

tis 2023-03-07 klockan 14:20 +0100 skrev Bruno Haible:
> Simon Josefsson wrote:
> > Consider adjusting your habit to update the libtool version
> > directly
> > AFTER a release instead.  I put the following in cfg.mk to make
> > sure I
> > don't forget this:
> > 
> > sc_libtool_version_bump:
> >         @git diff v$(PREV_VERSION).. | grep '^+AC_SUBST(LT' >
> > /dev/null
> > 
> > Of course, you still have to bump it if you make any API/ABI
> > changes,
> 
> Is a maintainer not _more_ likely to forget about the libtool
> versioning, when he has a rule like that, that makes him think "I'm
> already on the safe side, since I have done it already"?

Yes, maybe -- although but approaches are fragile and depend on
maintainer attention, so they are both sub-optimal.

I have used libabigail's abidiff to find API/ABI differences with good
results -- however, I don't know of a good way to check libtool shared
library versionining information against it.  Some brain storming how
it would work:

1) On 'make check' (or distcheck, or similar), do a abidiff of the
newly built library against a previously stored *.abi file and exit
with failure on differences (or if no file exists).

2) Add README notes to instruct maintainers to add known good new *.abi
files named like libfoo-x86_64-1-2-3.abi where 1-2-3 is the libtool-
version when any API/ABI-changes are made, or when libtool version is
bumped.  Maybe the '-3' part shouldn't be part of the filename.

3) for bonus points: Add some consistency check that the diff follows
libtool-semantics for ADDED vs MODIFIED ABI differences.

Not all API/ABI changes results in abidiff-changes, though, although
these days I think it is generally considered a bad idea to bump
libtool shared library version for anything but pure symbol changes. 
For semantical changes, introduce new APIs and deprecate the old ones
instead.

/Simon

signature.asc
Description: This is a digitally signed message part