[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Release management: how do you update the libtool version informatio
From: |
Simon Josefsson |
Subject: |
Re: Release management: how do you update the libtool version information? |
Date: |
Tue, 07 Mar 2023 17:51:44 +0100 |
User-agent: |
Evolution 3.44.4-0ubuntu1 |
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