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

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.