[Python-Dev] Re: Stability and change

[Guido van Rossum]

[Geoff Gerrietts]
>   When I looked at upgrading to the 2.* series of python interpreters,
>   I wasn't sure where to target. 2.0 is for all intents and purposes a
>   dead end. 2.1 is seeing some active bugfix development, but there's
>   no visible commitment from the community to continue that trend. In
>   fact, when the topic gets broached, it more often than not gets shot
>   down with "not likely, who would want to waste their time on doing
>   that?" or some variation therof. 2.2 appears stable, but there's a
>   bugfix release in the works that hasn't (as far as I know) been made
>   official yet. In other words, none of the 2.* series appeared like
>   particularly attractive targets to shoot at, because all of them
>   appeared to be unsuitable for the needs of our organization. I
>   decided to shoot for 2.2, because it's hard to tell when we'll be
>   able to do the upgrade again, and I wanted to solve as many problems
>   as could be solved, now. It appears that may have been a bad choice,
>   given progress with 2.1.3.

If you're coming from 1.5.2, picking 2.2, the most recent "final"
release, is the right choice.  Most breakage of 1.5.2 code was done in
2.0, when we didn't have warnings in place, and added Unicode.

2.1.3 is good for people who ar already on 2.1 and who want to see
some bugs fixed.  We fixed TONS of bugs in 2.1.1 and 2.1.2; 2.1.3 will
be released tonight with only a very small number of additional fixes,
but including one that happens to be important for some Zope users
(Zope can do some weird shit that you're not likely to run into
yourself :-).

2.2.1 will *also* be released tonight.  It fixes most known bugs in
2.2, adding almost no new features (depending on how the size of your
yardstick).  The idea is that anybody who would want to run 2.2 would
be even happier with 2.2.1, and that people who were afraid that 2.2
would crash an burn can now try out 2.2 without that fear.

>   People talk about a 6 month gap between releases, but I'm not sure
>   anyone recognizes that timeframe as "average" yet. You can have an
>   average with only two measurements, but it really takes three to
>   make a series, and the gap between 1.5.2 and 2.0 was considerably
>   longer than 6 months. The point here is that when you adopt any
>   given minor version of python, you have no idea how long you have
>   before you're obsolescent. Six months is reasonable, if that is in
>   fact what we continue to hit. But being predictable is more
>   important to "the conservative crowd" than any particular interval
>   could be.

Before 1.5.2, we *also* hit 6 months with some regularity.  The only
irregularity was really the 18 month gap between 1.5.2 and 2.0.  We're
seeing the gap slowly increase, to maybe 8 months for 2.3, but I
expect that 6-8 months is probably what we'll continue to see.

> In conclusion, I think that what "the conservatives" are looking for
> is really quite easy to provide. I summarize them as:
> 
> - Be predictable. If we're putting off pain until 3.0, make a guess
>   when we're going to need to deal with that pain, so we can start
>   preparing. If 3.0 is 9 months off, that's a lot scarier and more
>   concerning than if it's 2 years off.

3.0 will always be 2 years off. :-)  At least for now, it really is.

> - Be explicit about the process. If the process is to stick a fork in
>   the ham and call it "stable" just before moving on to the next minor
>   release, then be explicit about that process.

We are already pretty explicit; there are several PEPs about the
process.

> - Be explicit about obsolescence. If things in 2.3 or 3.0 or X.Y are
>   shaping up to be so different that bugfixes won't be back-portable,
>   then identify that fact early -- and make an effort to provide a
>   reasonable target for people to upgrade to, as soon as possible.

It depends on the bugfix.  Some modules and subsystems are being
refactored in order to provide new features, and then bugfixes won't
port back.  Other modules and subsystems are very stable (some could
be called stagnant :-) and will have no problem getting bugfixes
backported.

> The perceived problem with change being too rapid may be just that, a
> perceived problem. With adequate and careful communication, the
> problem may disappear entirely. It may not, but we can always dream.
> :)

Yes, maybe it can be made to disappear.  Does that mean we need to
throw the reactionaries on c.l.py a bone?  Is this really all
politics?  In that case I'm out of here.

> Anyway, that's about all I can contribute, after thinking long and
> seriously about what I feel like our company needs, and trying to
> ignore the specific details of implementation. I hope it's helpful.

Thanks!

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