On Thu, 2022-02-24 at 14:35 +0200, matti picus wrote:

Once again, I broke ABI compatibility with the new release. I re-added a field to PyDateTime_CAPI that should have been part of the original PyPy3.7 release, but was missed, and so should be left out of PyPy3.7 v7.3.x. This causes segfaults when using PyPy3.7-v7.3.8 on wheels built for PyPy3.7-v7.3.7 and older. Please do not build packages with PyPy3.7-v7.3.8 for general release because they will not work on older PyPy3.7.

What is doubly annoying is this is exactly why I needed to release v7.3.7 over v7.3.6. PRs welcome to suggest a test for this. A "hg diff" is a start, but it picks up refactoring and valid additions as well, so it needs to be a bit smarter. Maybe something with CFFI?

Perhaps abi-compliance-checker [1] could be of some help. It is quite good in detecting ABI breakage in "normal" C/C++ libraries. [1] https://lvc.github.io/abi-compliance-checker/ -- Best regards, Michał Górny

On Thu, 2022-02-24 at 14:35 +0200, matti picus wrote:

Once again, I broke ABI compatibility with the new release. I re-added a field to PyDateTime_CAPI that should have been part of the original PyPy3.7 release, but was missed, and so should be left out of PyPy3.7 v7.3.x. This causes segfaults when using PyPy3.7-v7.3.8 on wheels built for PyPy3.7-v7.3.7 and older. Please do not build packages with PyPy3.7-v7.3.8 for general release because they will not work on older PyPy3.7.

What is doubly annoying is this is exactly why I needed to release v7.3.7 over v7.3.6. PRs welcome to suggest a test for this. A "hg diff" is a start, but it picks up refactoring and valid additions as well, so it needs to be a bit smarter. Maybe something with CFFI?

Perhaps abi-compliance-checker [1] could be of some help. It is quite good in detecting ABI breakage in "normal" C/C++ libraries. [1] https://lvc.github.io/abi-compliance-checker/ -- Best regards, Michał Górny