Martin v. Löwis <martin <at> v.loewis.de> writes: > > Such a schedule was initially used for the first 2.x releases. We then > switched to 18 months because of user complaints: if releases come too > frequently, the users are confused as to what release they should be > using. Even 24 months is too frequently for some: some people are only > starting to move to 2.5 right now - when we have stopped maintaining > it already. Obviously, there are some users who value stability over everything else. While new language features are never critical and can easily be circumvented if you want your code to run on old Python versions, stdlib improvements can be more important for the average user. So perhaps the answer is the split that Brett proposed between core language and stdlib. > One question is what would happen to the old releases: would we still > maintain them? If so, how many of them? For how long? Yes, I realized that's one of the problems with this proposal. If we had to maintain more than one stable branch, it would become a burden.
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