[Python-Dev] Stability and Change (original) (raw)

Guido van Rossum guido@python.org
Tue, 09 Apr 2002 23:06:12 -0400

I missed this thread due to a heavy schedule and hope people won't mind one more comment. Let's be really blunt:

Frequent releases cost me money. [...] I desperately want to see a "recommended stable version" declared with intervals of 18 months or greater. [...] 24 months would be even better.

Thanks for a message from the trenches. (Alex can be really convincing, but I'm never quite sure if he's really been in trenches or if he's just a damn good storyteller. With Andy, I know he talks no bullshit.)

I've heard "18 months or more" from several (presumably) independent sources now. I'd like to give you that, but for me, as a developer, it feels like an eternity, and I'm more comfortable with 6-8 months for major releases (of the 2.2 kind).

How about this as a compromise: each major release (which for Python is 2.0, 2.1, 2.2, 2.3 etc., never mind that only the "minor" digit varies -- that's how we number 'em) has a shelf-life of at least three subsequent major releases or 24 months, whichever is shorter, but never less than 18 months. Shelf-life means that we follow up with bugfix releases (like 2.1.1, 2.1.2, 2.1.3) to maintain and improve stability, if necessary back-porting selected minor features, but with the absolute guarantee that (a) the binary API doesn't change, so C extensions are completely portable between bugfix releases, and (b) no old code break unless it depends on bugs being present or names being absent from any given namespace. (The latter qualification means that a bugfix release may add methods to classes, functions to modules, new modules or packages, and even built-in names; but it cannot take away, and it cannot change function signatures except by adding optional arguments. I believe this leeway is necessary to be able to add minor features.)

This means that once you pick a release, you can rest in peace for at least 18-24 months, without feeling left behind. You may have to teach your customers not to upgrade to the latest and greatest major release (but that doesn't seem to be a problem :-), but they should be comfortable picking up a bugfix release any time they feel like it without worrying about breaking something. More likely, they would only upgrade when you recommend that they do so (e.g. because you know it addresses a specific problem they've got), but these upgrades should be very smooth and free of surprises. (We've got some experience with that now with Zope users and various versions on the 2.1.x axis; it seems to work well.)

It may mean that you have to reel in your own developers a bit, since they have to develop for whatever Python release you've picked, so they may not be able to use the generators / bools / whatever they'd like to use. But that seems a minor inconvenience. I understand that a feature in the latest major release is harder to do without than a feature in CVS, but again, Zope current practice suggests that it's no big deal.

Comments?

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