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

Guido van Rossum guido@python.org
Mon, 08 Apr 2002 16:43:55 -0400

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