[ClusterLabs Developers] If anybody develops against libpe_status.so: skipped soname bump (in 2.0.2)

[Jan Pokorný]

On 14/06/19 18:46 -0500, Ken Gaillot wrote:
> On Fri, 2019-06-14 at 23:57 +0200, Jan Pokorný wrote:
>> On 14/06/19 14:56 -0500, Ken Gaillot wrote:
>>> On Fri, 2019-06-14 at 20:13 +0200, Jan Pokorný wrote:
>>>>> On Thu, 2019-06-06 at 10:12 -0500, Ken Gaillot wrote:
>>> Since those functions are internal API, we don't need a soname
>>> bump.  Distributing the header was a mistake and should not be
>>> considered making it public API. The only functions in there that
>>> had doxygen blocks were marked internal, so that helps.
>>> 
>>> As an aside, the entire libpe_status was undocumented until 2.0.1,
>>> but that was an oversight (a missing \file line).
>> 
>> In FOSS, (un)documentation aspect doesn't play that much of a role...
>> 
>>> In practice there were some projects that used it, and we did bump
>>> the soname for most functions. Now however it's documented
>>> properly, so the line should be clear.
>> 
>> Not at all, see above.
>> 
>> Traces of the pre-existing mess have some momentum.
>> 
>> Anyway, good to know the root cause, question is how to deal with
>> the still real fallout.
> 
> What's the fallout? An internal function

"sort of", but definitely only after said forthcoming change :-)

> that no external application uses changed

"sort of", but they could with the header interpretable as public
(since Pacemaker-1.1.15), just wasn't discovered before (I don't
think I ever tried to match the changes back to the headers, plus
how these headers are to be interpreted)

> which doesn't require a soname bump.
> 
> I'll handle it by renaming the header and moving it to noinst.

Yes, that will help going forward.

This thread hopefully (justly) mitigates any surprising sharp edges
till this point (effectively towards any potential usage accustomed
in 1.1.15 - 2.0.1 timespan) should there be any.

Anyway, it looks like libabigail is a very useful tool we might
consider alongside or instead of abi-compliance-checker.
It looks like it can be told precisely which headers are private
and which not, so there could be even be some sort of authoritative
listing (regardless of documentation or not, as mentioned, that's
secondary with FOSS projects) to source that from.

One idea there would be to add another, standalone pass to our
Travis CI tests that would leverage TRAVIS_COMMIT_RANGE env. variable
(too bad that it's all stateless, without any convenient lookaside
storage, or is there?) to get the two builds (looks like it could
naturally be done in rather an efficient manner) for a subsequent
ABI comparison.  Either merely "informative" (i.e., pass unless there's
an actual build failure), or "punishing" if we can afford to switch
more into "always ready" paradigm (which CI is all about) -- when the
pull request destructs the ABI in some not-mere-addition way (while
soname bump didn't occur?  or when there are at least any API-ABI
hurdles found?), raise a flag.  It would then be up to deliberation
whether it's a blocker or not.  But would attract the attention for
sure, hence more care, in an ahead-of-time fashion.

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/developers/attachments/20190619/60eda254/attachment.sig>