> Jeremy> The question, then, is whether some amount of incompatible > Jeremy> change is acceptable in the 2.1 release. > > I think of 2.1 as a minor release. Minor releases generally equate in my > mind with bug fixes, not significant functionality changes or potential > compatibility problems. I think many other people feel the same way. Hm, I disagree. Remember, back in the days of Python 1.x, we introduced new stuff even with micro releases (1.5.2 had a lot of stuff that 1.5.1 didn't). My "feel" for Python version numbers these days is that the major number only needs to be bumped for very serious reasons. We switched to 2.0 mostly for PR reasons, and I hope we can stay at 2.x for a while. Pure bugfix releases will have a 3rd numbering level; in fact there will eventually be a 2.0.1 release that fixes bugs only (including the GPL incompatibility bug in the license!). 2.x versions can introduce new things. We'll do our best to keep old code from breaking unnecessarily, but I don't want our success to stand in the way of progress, and I will allow some things to break occasionally if it serves a valid purpose. You may consider this a break with tradition -- so be it. If 2.1 really breaks too much code, we will fix the policy for 2.2, and do our darndest to fix the code in 2.1.1. > Earlier this month I suggested that adopting a release numbering scheme > similar to that used for the Linux kernel would be appropriate. Please no! Unless you make a living hacking Linux kernels, it's too hard to remember which is odd and which is even, because it's too arbitrary. > Perhaps it's not so much the details of the numbering as the > up-front statement of something like, "version numbers like x.y > where y is even represent stable releases" or, "backwards > incompatibility will only be introduced when the major version > number is incremented". It's more that there is a statement about > stability vs new features that serves as a published committment the > user community can rely on. After all the changes that made it into > 2.0, I don't think anyone to have to address compatibility problems > with 2.1. I don't want to slide into version number inflation. There's not enough new in 2.1 to call it 3.0. --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