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

Terry Reedy tjreedy at udel.edu
Wed Jan 18 00:29:11 CET 2012

On 1/17/2012 3:34 PM, Antoine Pitrou wrote:
> Hello,
> We would like to propose the following PEP to change (C)Python's release
> cycle. Discussion is welcome, especially from people involved in the
> release process, and maintainers from third-party distributions of
> Python.
> Regards
> Antoine.
> PEP: 407
> Title: New release cycle and introducing long-term support version

To me, as I understand the proposal, the title is wrong. Our current 
feather releases already are long-term support versions. They get bugfix 
releases at close to 6 month intervals for 1 1/2 -2 years and security 
fixes for 3 years. The only change here is that you propose, for 
instance, a fixed 6-month interval and 2 year period.

As I read this, you propose to introduce a new short-term (interim, 
preview) feature release along with each bugfix release. Each would have 
all the bugfixes plus a preview of the new features expected to be in 
the next long-term release. (I know, this is not exactly how you spun it.)

There has been discussion on python-ideas about whether new features are 
or can be considered experimental, or whether there should be an 
'experimental' package. An argument against is that long-term production 
releases should not have experimental features that might go away or 
have their apis changed.

If the short-term, non-production, interim feature releases were called 
preview releases, then some or all of the new features could be labelled 
experimental and subject to change. It might actually be good to have 
major new features tested in at least one preview release before being 
frozen. Maybe then more of the initial bugs would be found and repaired 
*before* their initial appearance in a long-term release. (All of this 
is not to say that experimental features should be casually changed or 
reverted without good reason.)

One problem, at least on Windows, is that short-term releases would 
almost never have compiled binaries for 3rd-party libraries. It already 
takes awhile for them to appear for the current long-term releases. On 
the other hand,  library authors might be more inclined to test new 
features, a few at a time, if part of tested preview releases, than if 
just in the repository. So the result *might* be quicker library updates 
after each long-term release.

Terry Jan Reedy

More information about the Python-Dev mailing list