[me] > > 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. [Alex] > 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. Yes. > 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. *If* the community likes the even/odd distinction enough. I've heard mixed feelings. --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