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

[Antoine Pitrou]

On Tue, 17 Jan 2012 18:29:11 -0500
Terry Reedy <tjreedy at udel.edu> wrote:
> 
> 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.)

Well, "spinning" is important here. We are not proposing any "preview"
releases. These would have the same issue as alphas or betas: nobody
wants to install them where they could disrupt working applications and
libraries.

What we are proposing are first-class releases that are as robust as
any other (and usable in production). It's really about making feature
releases more frequent, not making previews available during
development.

I agree "long-term" could be misleading as their support duration is
not significantly longer than current feature releases. I chose this
term because it is quite well-known and well-understood, but we could
pick something else ("extended support", "2-year support", etc.).

> 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.

That's orthogonal to this PEP.
(that said, more frequent feature releases are also a benefit for the
__preview__ proposal, since we could be more reactive changing APIs in
that namespace)

> One problem, at least on Windows, is that short-term releases would 
> almost never have compiled binaries for 3rd-party libraries.

That's a good point, although Py_LIMITED_API will hopefully make things
better in the middle term.

Regards

Antoine.