[Python-Dev] Re: Stability and change (original) (raw)

Guido van Rossum guido@python.org
Mon, 08 Apr 2002 20:26:46 -0400

BTW, as to libraries and /F's comments... I think the library modules should always have to lag at least one release behind the interpreter. Maybe 2? This gives a couple of things:

- No introducing weird problems in the library to compound compatibility issues

Why would using a new feature introduce a weird problem in the library? Name one feature where this has happened in the past.

- Iron out new features/changes by letting those people actually using them benefit/feel the pain, before we make the general populace deal.

I don't understand how not using a feature in the library means that the people actually using the feature feel the pain.

To the contrary, starting to use a new feature in the library helps me understand the strengths and weaknesses of the feature.

(I would make an exception for library modules that have a life outside the standard library, like /F's SRE. But there aren't many of those -- maybe the email package, although it works the other way around: it evolves outside the library until it's ready for inclusion.)

Again, I think stating what "policy" is about support for older releases is solves a HUGE amount of the problem. And probably a bigger percentage than a numbering scheme ever could.

I'd be happy to state that we'll keep 2.1.x up to date whenever issues arrive, within the limitations of our resources. That probably means that we'll need a new community member to help backporting bugfixes.

For 2.2.x I'm willing to make a stronger promise: I'd like to try to fix all bugs in 2.2.x as well as in 2.3, as long as 2.2 is considered more stable than 2.3 (this is trivially true until at least 2.3.1 is released :-). Resources are still a problem, so help is appreciated. But I think making 2.2.x as strong as possible sounds like a good goal.

--Guido van Rossum (home page: http://www.python.org/~guido/)