Python releases [was Long: Python Is Really Middleware]

[Chui Tey]

Truely insightful, especially the warning on creeping featurism.

There is so much 'new' technology abound nowadays that I would be very happy
if something remained invariant for a little bit longer. The rapid cycle of
python releases, some backwards incompatible means people have to be very
careful about upgrading lest it breaks their existing libraries, some which
they might not have written themselves.

How often should releases be? There probably could be two kinds of releases:

a) Petrified: Locked in stone. (1.52 is a classic example)

Both language and library are stable.

Libraries (official or third party) can be released against these in the
expectation that all python users would probably want to have a copy of each
petrified release installed. I say this coming from the win32 perspective
that a lot of extensions are already precompiled, and that is a definite
plus since it is a real time-saver. There is no reason why more third party
precompiled extensions can't be supplied for the more common platforms as
well. It's the m x n problem of the many platforms and the many versions of
python around.

This also helps people making RPMs or Debian distributions to decide what
versions to make available in their general releases.

People working on libraries can supply patches against these kind of
releases as a matter of priority, since they know that this is a widely
installed base.

Petrified releases could be perhaps a year or more apart and may break
backward compatibility.  But they break compatibility only once a year.
Programs written in these  releases do not need to import from __future__.

b) Stable Enhanced: These are the major releases that we have now - 1.6,
2.0, 2.1 and could break backward compatibility, but libraries using the new
backwards incompatible functions ought to import from __future__.