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

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