[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