On Monday 08 April 2002 07:24 pm, Guido van Rossum wrote: ... > 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. It seems to me that the "stabilization" point SHOULD be more clearly marked -- get the message out "this IS stable and reliable, anything written for this release will not break in future releases of the same major.minor" in a very clear way. It seems to me that duplicating (in your example) 2.3.8 to 2.4.0 (and using 2.5.0 as the new baseline for further experimentation) would be a very clear signal in this sense. Alex
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