On 2024-Feb-27, Peter Geoghegan wrote:
> On Tue, Feb 27, 2024 at 8:25 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> > The way I see this working, is that we set up a buildfarm animal [per
> > architecture] that runs the new rules produced by the abidw option and
> > stores the result locally, so that for stable branches it can turn red
> > when an ABI-breaking change with the previous minor release of the same
> > branch is introduced. There's no point on it ever turning red in the
> > master branch, since we're obviously not concerned with ABI changes there.
>
> ABI stability doesn't seem like something that you can alert on.
Eh, I disagree. Since you can add suppression rules to the tree, I'd
say it definitely is.
If you commit something and it breaks ABI, we want to know as soon as
possible -- for example suppose the ABI break occurs during a security
patch at release time; if we get an alert about it immediately, we still
have time to fix it before the mess is released.
Now, if you have an intentional ABI break, then you can let the testing
system know about it so that it won't complain. We could for example
have src/abi/suppressions/REL_11_8.ini and
src/abi/suppressions/REL_12_3.ini files (in the respective branches)
with the _bt_pagedel() change. You can add this file together with the
commit that introduces the change, if you know about it ahead of time,
or as a separate commit after the buildfarm animal turns red. Or you
can fix your ABI break, if -- as is most likely -- it was unintentional.
Again -- this only matters for stable branches. We don't need to do
anything for the master branch, as it would be far too noisy if we did
that.
Now, maybe a buildfarm animal is not the right tool, and instead we need
a separate system that tests for it and emails pg-hackers when it breaks
or whatever. That's fine with me, but it seems a pretty minor
implementation detail.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
