[Python-Dev] "Unstable" is an ambiguous word...

[Alex Martelli]

On Monday 08 April 2002 06:39 pm, Andrew Kuchling wrote:
	...
> otherwise.  (Though who decides when it stops being experimental?
> Everyone here on python-dev thought 2.2 was OK, and I use 2.2 every
> day without pain, so I don't really know what people are complaining

2.2 is a quite-stable piece of software, per se.  When you ask if a
piece of software is stable, out of context, you normally think of
crashes and other sundry bugs.  In that sense, the complaints are
not well-founded, in my opinion.

The Python language was not 'stable' between 2.1.* and 2.2 : some
previously correct programs stopped working.  That's according to
plan.  BUT -- that plan is a problem for people who need their code,
if correct, to keep working for longer than the 6 months between
minor releases.  Right now we're telling them to stick with (e.g.)
2.1 and just hope that somebody is interested enough to backport
bug fixes, enhancements that would break nothing (such as new
library modules) or "nothing important" (a far harder call!-), and so
on.  I do not think this is optimal.

On one hand it may over-constrain Guido from release to release.
He can't put a feature in 2.3 without thereby befoming unable to take it
away again, or redo it in some incompatible way, should it prove 
imperfect.  If 2.3 was an admittedly experimental release, he COULD
choose to take more risks in this sense!  He may afford a little bit
less stability in the design of languages he releases (not necessarily
in terms of "it crashes every minute" -- that's ANOTHER sense of
"stable"... the one I was mentioning 2 para's ago, and the one I
think you're asking about).

On the other hand, software dev't managers don't like the choice
between an "old, obsolete, probably not of interest any more" piece
of software, and one that's "so brand-new it's still churning AND
may break your existing correct code".

It seems to me that trying to reasonably meet all needs within one
"track" of development is doomed to fail, while "two tracks" would
afford a better chance.  The "stable" track would focus on not
breaking existing correct programs; the "experimental" track would
focus on enhancements with more freedom (including freedom to
take some language-design risks).

Thus, "who decides" would have to be GvR -- but it woulnd't most
likely be twice a year that the stable track gets to a head  and
needs a new baseline (stabilized from a line of experimental
track releases).  The lucky accident of 1.5.2's long stability, which
attracted so many to Python, would ideally be reproduced by
design... or so one can hope.


Alex