Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
| От | Bruce Momjian | 
|---|---|
| Тема | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() | 
| Дата | |
| Msg-id | aQKGF1OnClNRY4j4@momjian.us обсуждение исходный текст  | 
		
| Ответ на | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() (Tom Lane <tgl@sss.pgh.pa.us>) | 
| Ответы | 
                	
            		Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
            		
            		 | 
		
| Список | pgsql-hackers | 
On Fri, Oct 17, 2025 at 07:07:36PM -0400, Tom Lane wrote: > "David E. Wheeler" <david@justatheory.com> writes: > > On Oct 17, 2025, at 17:51, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> NO. The rule is: if there's no such file, do not apply ABI checking. > >> We are not interested in ABI complaints against master. > > > It only runs against maintenance branches. > > That seems overcomplicated: how does the buildfarm know > what's a maintenance branch? I think the rule should be > just "run ABI checks if the control file exists, else not". > > As an example of why that's better, what if we did decide > we wanted ABI checks on master? I assume we would want ABI breakage checks on master between Beta 1 and the time we branch for the new major release in July. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.
В списке pgsql-hackers по дате отправления: