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

[Guido van Rossum]

So, to summarize, we need something like six for C?

On Tue, Jun 12, 2018 at 5:38 AM, Nick Coghlan <ncoghlan at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180612/ccea9a9b/attachment.html>