Nathan Bossart <nathandbossart@gmail.com> writes:
> For the rest of the back-branches, I'm considering starting with a baseline
> of the latest minor version stamps. While it would be nice to have a
> comprehensive history of the ABI compatibility for each major version,
> we've lived this long without it, and I think it's unlikely that we'd act
> on any breakages that predate the latest release set. Thoughts?
Agreed that building a full list of ABI-changing commits in those
branches is probably not worth the trouble at this point. (My OCD
side kind of wants to do it anyway ... but it's hard to argue that
we'd get real value out of it, or that we'd change anything now
unless we get complaints.)
I searched the commit log, and found that the most recent intentional,
or at least documented-in-the-log, ABI break was here:
Author: Masahiko Sawada <msawada@postgresql.org>
Branch: master Release: REL_18_BR [d87d07b7a] 2025-06-16 17:36:01 -0700
Branch: REL_17_STABLE Release: REL_17_6 [45c357e0e] 2025-06-16 17:35:58 -0700
Branch: REL_16_STABLE Release: REL_16_10 [b2ae07720] 2025-06-16 17:35:55 -0700
Branch: REL_15_STABLE Release: REL_15_14 [fc0fb77c5] 2025-06-16 17:35:53 -0700
Branch: REL_14_STABLE Release: REL_14_19 [983b36362] 2025-06-16 17:35:50 -0700
Branch: REL_13_STABLE Release: REL_13_22 [1230be12f] 2025-06-16 17:35:48 -0700
...
Note that this commit adds two new fields to ReorderBufferTXN to store
the distributed transactions. This change breaks ABI compatibility in
back branches, affecting third-party extensions that depend on the
size of the ReorderBufferTXN struct, though this scenario seems
unlikely.
...
I propose that we should make .abi-compliance-history point at these
commits rather than REL_17_6 et al. If there is anything later than
this that affected ABI, it'd be worth finding out I think, even though
we might choose not to do anything about it. (In effect, we'd be
starting the ABI compliance histories there rather than all the way
back at the .0 releases.)
regards, tom lane
