[Python-Dev] What version is an extension module binary compatible with

[Nathaniel Smith]

On Mar 28, 2017 10:54 AM, "Steve Dower" <steve.dower at python.org> wrote:

On 28Mar2017 1035, Paul Moore wrote:

> On 28 March 2017 at 18:05, Glenn Linderman <v+python at g.nevcal.com> wrote:
>
>> Somewhere I got the idea that extension authors were supposed to build
>> against the n.m.0 releases, expressly so that the extensions would then be
>> compatible with the whole n.m.x series of releases. Did I dream that?
>>
>
> I've certainly never heard it stated - and I'd think it's a pretty
> annoying requirement to make of extension builders.
> Paul
>

Agreed, we should avoid both additive and subtractive breaking changes to
the binary API within micro versions completely. Additive ones like this
are difficult to catch, unfortunately, and so building against the .0
release is not bad advice. Building with the .0 headers is probably
sufficient.

I wonder if there's a way we can preprocess the headers to define a
baseline? Then we could automatically compare against that and force
explicit decisions leading to public API changes (probably the process of
finishing off the limited API validation could include this task fairly
easily as well).


It wouldn't be as fancy as analyzing the headers, but a much easier and
still useful way to get started would be a test to check no new exported
symbols appear in the shared library during a stable release cycle.

If you want to get quite fancy, libabigail provides a toolkit that can read
debug information and check that all your structs remain the same size etc.
ELF only, but still would catch a lot:

https://sourceware.org/libabigail/manual/libabigail-overview.html

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170328/3b3ee47c/attachment.html>