Skip wrote: > I think an important question is what happens to the 2.2.x branch once > 2.4.0 is released? Should it die (in the sense of *never* getting > another micro release)? I think that would be a fair approach, > otherwise you have an ever-increasing support burden, trying to handle > more and more releases. Was there ever a huge clamor for 1.5.3? It > seems that for many people the heavens opened and Gabriel descended > with a 1.5.2 CD. ;-) I'd agree with that in the abstract. But then I realize that I'm still writing for 1.5.2, estimate that it would probably take a month or two to update 10K lines of C extension code to 2.0, 2.1, and 2.2, realize that I just don't have the time, and cringe away from the whole idea. My wish as an extension developer would be for Python to be stable for a year at a time, and then change to a new stable version that would last for another year. Then I could keep my extension code reasonably up to date by devoting one concentrated month per year. Maybe the problem is not as bad as I percieve it; but I can't afford the time to find out. That's why I like the idea of separate stable and experimental tracks--the language evolution happens and I get the benefits, but I don't have to constantly keep up with it. Paul Hughett
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