[Python-Dev] Stability and Change

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