[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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4