[Python-Dev] Re: Stability and change

[Guido van Rossum]

[me]
> >Cheap shots aside, another possibility would be to simply start
> >*every* minor (2.x) release off as unstable, releasing frequent
> >experimental micro (2.x.y) releases as a substitute for alpha/beta
> >releases, and then at some point declare it stable.  

[AMK]
> I like this approach because it matches what the community seems to
> actually be doing: the latest release is "experimental" until told
> 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
> about.)

Maybe different user sub-communities can keep their own table of which
versions they consider sufficiently stable to use.  E.g. I can see
Zope Corp declaring Python 2.1.3 the holy grail for Zope 2.5 and 2.6,
but the Zope 3 developers will probably want to start using 2.3 ASAP.

All the Python developers need to do is decide on a point where they
won't allow incompatible changes to new features between micro
releases.  Currently that point is the release of the "final" release
of a minor version (e.g. 2.2).  I can see that point shifting to a
later micro release for future minor releases, so that e.g. 2.3, 2.3.1
up to 2.3.7 may contain incompatible features, but 2.3.8 and later
must be compatible with 2.3.7.

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