Didn't 3.5 have to roll an extra last minute RC for an emergency abi-breaking bug fix, though? (Thinking of the windows runtime stuff.)


On Nov 16, 2016 7:51 PM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
On 17 November 2016 at 10:44, Steve Dower <steve.dower@python.org> wrote:
> On 16Nov2016 1618, Ned Batchelder wrote:
>> Am I doing the wrong thing by using PyCodeObject fields directly in the
>> coverage.py C trace function?  It seems like this was an unnecessary
>> breaking change, even if it is a non-guaranteed interface.
>
> I suspect the "wrong thing" here is expecting to not see any changes between
> alpha/beta versions. It certainly should not change within 3.6.x, so your
> wheel build will be fine, but changing during the prerelease versions is a
> possibility for anything not in the limited ABI.

Right, and we don't have an explicit policy on when the ABI gets
locked prior to the x.y.0 release other than the general rule of
"minimise change after the first release candidate".

This question also came up on the wheel-builders list in the context
of "When can Python 3.6 support be added to the published manylinux1
build environments without risking ABI incompatible wheels on final
release?".

Perhaps it would make sense to declare the final beta the last
opportunity for public ABI changes? That would give folks a few weeks
to start preparing launch binaries if they want to do so, rather than
the single week planned between the rc and the final release.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/njs%40pobox.com