[Python-Dev] Re: Stability and change

[Guido van Rossum]

> 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/)