<div dir="auto"><div><div class="gmail_extra"><div class="gmail_quote">On Mar 28, 2017 10:54 AM, "Steve Dower" <<a href="mailto:steve.dower@python.org">steve.dower@python.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On 28Mar2017 1035, Paul Moore wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 28 March 2017 at 18:05, Glenn Linderman <<a href="mailto:v%2Bpython@g.nevcal.com" target="_blank">v+python@g.nevcal.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Somewhere I got the idea that extension authors were supposed to build<br>
against the n.m.0 releases, expressly so that the extensions would then be<br>
compatible with the whole n.m.x series of releases. Did I dream that?<br>
</blockquote>
<br>
I've certainly never heard it stated - and I'd think it's a pretty<br>
annoying requirement to make of extension builders.<br>
Paul<br>
</blockquote>
<br></div>
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.<br>
<br>
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).<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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:</div><div dir="auto"><br></div><div dir="auto"><a href="https://sourceware.org/libabigail/manual/libabigail-overview.html">https://sourceware.org/libabigail/manual/libabigail-overview.html</a><br></div><div dir="auto"><br></div><div dir="auto">-n</div></div>