[Python-Dev] PEP 407: New release cycle and introducing long-term support versions (original) (raw)
Antoine Pitrou solipsis at pitrou.net
Wed Jan 18 00:42:21 CET 2012
- Previous message: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
- Next message: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
- Next message: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]