So, to summarize, we need something like six for C? On Tue, Jun 12, 2018 at 5:38 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> Hi folks, > > Given the discussion of adopting an annual release cadence at the language > summit this year [1], this recent Jakarta (nee Java) EE announcement caught > my attention: https://www.eclipse.org/ee4j/news/?date=2018-06-08#release- > cadence > > JEE are switching to an annual update cadence for the base platform, with > quarterly updates for individual components. > > Since we last seriously discussed potential release cadence changes back > in 2012 (with PEPs 407 and 413 [2,3]), that means JEE joins GCC switching > to an annual release cadence from GCC 5 back in 2015 (see [4]), while > clang/LLVM have been doing twice-annual feature releases for several years > now [5]. > > Most directly relevant to Python would be the Node.js maintenance > lifecycle initially developed in 2013, and evolved since then: > https://github.com/nodejs/Release > > That's quite a fast lifecycle (even faster than we're considering - they > do a release every 6 months, with every 2nd release being supported for 3 > 1/2 years), but one of the keys to making it work in practice is > https://github.com/nodejs/nan > > The gist of the "Native Abstractions for Node.js" project is that it aims > to provide a stable API & ABI for third party libraries to link against, > but *without* having to keep those interfaces stable in V8/Node.js itself. > > In the Python world, the closest current equivalent would by SIP for PyQt > projects [6], which provides a shim layer that allows version independent > extension modules to target CPython's native stable ABI with the aid of a > single version specific dependency (so only the "sip" wheel itself needs to > be rebuilt for each new Python version, not every extension module that > depends on it). > > So I expect a release cadence change would be a lot more viable now than > it would have been 6 years ago, but I also suspect actually getting there > will require a non-trivial amount of effort invested in generalising the > SIP model such that the stable ABI gets a *lot* easier for projects to > realistically target (including for cffi and Cython generated extension > modules). > > Cheers, > Nick. > > [1] https://lwn.net/Articles/755224/ > [2] https://www.python.org/dev/peps/pep-0407/ > [3] https://www.python.org/dev/peps/pep-0413/ > [4] https://gcc.gnu.org/releases.html > [5] https://releases.llvm.org/ (Note: LLVM switched to twice-yearly X.0.0 > releases in 2017, but were doing twice yearly X.Y releases for some time > before that) > [6] https://pypi.org/project/SIP/ > > > -- > Nick Coghlan | ncogh...@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/ > guido%40python.org > > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ 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/archive%40mail-archive.com
