[Python-Dev] Re: Stability and change (original) (raw)

Guido van Rossum guido@python.org
Mon, 08 Apr 2002 13:24:24 -0400

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