[Python-Dev] PEP 407: New release cycle and introducing long-term support versions

Georg Brandl g.brandl at gmx.net
Wed Jan 18 08:55:08 CET 2012

Am 18.01.2012 01:24, schrieb Jeff Hardy:
> On Tue, Jan 17, 2012 at 3:50 PM, Ezio Melotti <ezio.melotti at gmail.com> wrote:
>> * What is the effect on PyPy/Jython/IronPython?  Can they just skip the
>> feature releases and focus on the LTS ones?
> At least for IronPython it's unlikely we'd be able track the feature
> releases. We're still trying to catch up as it is.
> Honestly, I don't see the advantages of this. Are there really enough
> new features planned that Python needs a full release more than every
> 18 months?

Yes, we think so.  (What is a non-full release, by the way?)

The main reason is changes in the library.  We have been getting complaints
about the standard library bitrotting for years now, and one of the main
reasons it's so hard to a) get decent code into the stdlib and b) keep it
maintained is that the release cycles are so long.  It's a tough thing for
contributors to accept that the feature you've just implemented will only
be in a stable release in 16 months.

If the stdlib does not get more reactive, it might just as well be cropped
down to a bare core, because 3rd-party libraries do everything as well and
do it before we do.  But you're right that if Python came without batteries,
the current release cycle would be fine.

(Another, more far-reaching proposal, has been to move the stdlib out of
the cpython repo and share a new repo with Jython/IronPython/PyPy.  It could
then also be released separately from the core.  But this is much more work
than the current proposal.)


More information about the Python-Dev mailing list