[Python-Dev] Some data points for the "annual release cadence" concept

[Ronald Oussoren]

> On 13 Jun 2018, at 15:42, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> On 13 June 2018 at 02:23, Guido van Rossum <guido at python.org <mailto:guido at python.org>> wrote:
> So, to summarize, we need something like six for C?
> 
> Yeah, pretty much - once we can get to the point where it's routine for folks to be building "abiX" or "abiXY" wheels (with the latter not actually being a defined compatibility tag yet, but having the meaning of "targets the stable ABI as first defined in CPython X.Y"), rather than feature release specific "cpXYm" ones, then a *lot* of the extension module maintenance pain otherwise arising from more frequent CPython releases should be avoided.
> 
> There'd still be a lot of other details to work out to turn the proposed release cadence change into a practical reality, but this is the key piece that I think is a primarily technical hurdle: simplifying the current "wheel-per-python-version-per-target-platform" community project build matrices to instead be "wheel-per-target-platform”.

This requires getting people to mostly stop using the non-stable ABI, and that could be a lot of work for projects that have existing C extensions that don’t use the stable ABI or cython/cffi/… 

That said, the CPython API tends to be fairly stable over releases and even without using the stable ABI supporting faster CPython feature releases shouldn’t be too onerous, especially for projects with some kind of automation for creating release artefacts (such as a CI system).

Ronald

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180613/fb71c858/attachment.html>