Peter Eisentraut <peter@eisentraut.org> writes:
> On 12.09.25 16:52, David E. Wheeler wrote:
>> Excellent! But an example like this presumably helps make Tom’s case that each branch could have a file that
suggestswhich commit to use as the base for comparison, so that in this example it could be set to 344662848ac and the
failureswould go away. As it is, they will persist until a new tag is added or one overrides the base in the build farm
clientconfig.
> I don't think we need any ABI checking until there is a dot-0 release,
> so I don't agree that a facility like that is needed. Just compare
> against the previous release tag.
My concern is that when we get a report, we might decide to apply
some fix to remove the ABI delta, or we might decide it's intentional
and/or harmless and leave the code as-is. In the latter case, the
ABI-checking BF animal(s) will be red until the next release is made,
which helps nobody, particularly because it will probably interfere
with noticing any ABI breaks in later commits.
So I think we do need a way to move a branch's baseline that is not
rigidly tied to making a release. The only way we could possibly use
this testing methodology without that is if the ABI checker agrees
100.00% with our opinion of what is or is not a breaking change.
Which we already see isn't so. A concrete example is the hack we
frequently use of sandwiching a new field into what had been padding
space. I would be astonished if an ABI checker doesn't flag that,
but the checker's output doesn't make it not OK.
I'm not wedded to any particular way of implementing that, though
I'd prefer to avoid basing it on git tags given that they can't
readily be deleted or moved.
regards, tom lane
