Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
| От | Robert Haas | 
|---|---|
| Тема | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() | 
| Дата | |
| Msg-id | CA+Tgmob2gLaDeeJDjCtWe_xuac1XkTmip4raR_4isYMvkO0yBw@mail.gmail.com обсуждение исходный текст  | 
		
| Ответ на | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() ("David E. Wheeler" <david@justatheory.com>) | 
| Ответы | 
                	
            		Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
            		
            		 | 
		
| Список | pgsql-hackers | 
On Thu, Oct 30, 2025 at 8:42 AM David E. Wheeler <david@justatheory.com> wrote: > Might I suggest, however, that it also run for branches matching /_STABLE$/ even if there is no .abi-hstory-file? The wholepoint of this exercise was to increase the confidence in ABI stability in stable branches. Running it in such brancheswould help remind maintainers to add the file. I think it is better to do as Tom suggests -- i.e. have a buildfarm client that only cares about the presence of the file, and not at all about the name of the branch. That gives us the maximum amount of future flexibility for no real cost. Said differently, if somebody nukes the ABI history file from a back-branch, I think we should assume that represents a deliberate decision on the part of the project to stop caring about ABI compatibility in that particular back-branch, not an error that the build-farm needs to flag. Of course, if somebody wants to argue that such a decision was wrongly made, they're free to do so on pgsql-hackers, but we'd like the buildfarm to be green rather than red while that's being litigated. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: