[Python-Dev] Release Schedules (was Stability & change)

Raymond Hettinger python@rcn.com
Tue, 9 Apr 2002 01:32:51 -0400


From: Neal Norwitz <neal@metaslash.com>
> There seem to be two groups:
>
>  1) Early adopters: release early, release often; more features the better
>  2) The masses: easy does it, don't break anything, don't release so often
>
> I believe we can satisfy both groups--not perfectly, but good enough.
>
> This is partly summary and partly suggestion for terminology
> and schedule.  I propose doing:
>
>  Release name/type Version Schedule
>  ----------------- ------- --------
>  Major releases 2.4 1.5 - 3 years
>  Bugfix releases 2.2.1 ~ 3 months or as needed
>  Development releases 2.3a0 ~ 3 months

Before deciding on an overly conservative response, consider whether
the real issues are behind us.  List comprehensions and the like
were perceived as large changes.  In contrast, a series of 6 months
releases may be be more universally desired for the key things on
the table like optimization, logging, and a more robust library.

The anti-change cult may have drawn the line at augmented
assignment and are prepared to rage for an eternity at print >>,
but, even they, have not chafed at the new email module or
the addition of pydoc or unittest.  Further, they will surely
welcome a refactored parser, an exposed parser, unified ints/longs,
and optimized variable access.

IOW, I believe that major, useful changes can be made without
enraging the anti-change crowd.  Improving the product, fixing
bugs, expanding the library, filling in missing features, optimizing,
and instrumenting aren't the issue.  Just don't mess with the syntax
and people won't freak.


Raymond Hettinger


P.S.  The one area I'm less certain about is Deprecation.  Phasing
out lambda, map, and filter would please many but may have an
equally strong counter-reaction.  It's hard to tell (sometimes I
think I'm the only one who like the functional stuff).

P.S.S. I think the intensity of reaction to PEP 285 has to do with
it being central to future programming style.  It will affect and
appear in programs across the board.  Essentially, this proposal
will be as pervasive as a change to the grammar would be.