Nathan Bossart <[email protected]> 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 <[email protected]> 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
