Re: ABI Compliance Checker GSoC Project
От | Mankirat Singh |
---|---|
Тема | Re: ABI Compliance Checker GSoC Project |
Дата | |
Msg-id | CAOtk82RrME_MY9oCie0TV=NKbuXM0B16c1U_oUpe4oE8BnpB6w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ABI Compliance Checker GSoC Project (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ABI Compliance Checker GSoC Project
Re: ABI Compliance Checker GSoC Project |
Список | pgsql-hackers |
On Sun, 13 Jul 2025 at 05:42, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Nitpick: I think something is backwards about the labeling. AFAICS > the described ABI change was made by 53cd0b71e not its predecessor > 9dcc76414. It does look like a useful bit of information once > correctly attributed, though. Thanks for pointing that out, I'll fix it! > What we are going to want to know is if there are any ABI breaks in a > stable branch since the last release point. Once something turns up > in that view, it'd be good to be able to drill down to exactly which > commit(s) caused the changes. But nobody is going to want to leaf > through dozens or hundreds of per-commit reports, most of which should > be totally uninteresting for this purpose (in a back branch anyway). > Also, assuming we take action to undo the break, the cancelling-out > commits are no longer interesting, but we want to ensure that indeed > the ABI break is gone. So in my mind, ABI diff between last release > and branch tip is going to be the normal thing to want to see. Got your point. Here, I had a proposal: In case an ABI break is found, then loop through the commits after the last run to find the offending commit. We can also give the animal owner the option to decide whether they want to use their own machine to perform this search or not. Let me know your thoughts on this. Regards, Mankirat
В списке pgsql-hackers по дате отправления: