On 1/17/2012 6:42 PM, Antoine Pitrou wrote:
On Tue, 17 Jan 2012 18:29:11 -0500
Terry Reedy<tjre...@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.)
The main point of my comment is that the new thing you are introducing
is not long-term supported versions but short term unsupported versions.
Well, "spinning" is important here. We are not proposing any "preview"
releases. These would have the same issue as alphas or betas: nobody
I said nothing about quality. We aim to keep default in near-release
condition and seem to be getting better. The new unicode is still
getting polished a bit, it seems, after 3 months, but that is fairly
unusual.
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).
But I am dubious that releases that are obsolete in 6 months and lack
3rd party support will see much production use.
It's really about making feature releases more frequent,
> not making previews available during development.
Given the difficulty of making a complete windows build, it would be
nice to have one made available every 6 months, regardless of how it is
labeled.
I believe that some people will see and use good-for-6-months releases
as previews of the new features that will be in the 'real', normal,
bug-fix supported, long-term releases.
Every release is a snapshot of a continuous process, with some extra
effort made to tie up some (but not all) of the loose ends.
--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
