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)
pgpqwV0p9BA0e.pgp
Description: PGP signature
_______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/developers ClusterLabs home: https://www.clusterlabs.org/