Antoine Pitrou writes: > Just food for thought here, but seeing how 3.1 is going to be a > real featureful schedule despite being released shortly after 3.0, > wouldn't it make sense to tighten future release planning a little? With all due respect, it's easy and natural to have a short, featureful release schedule immediately after a major release (or should I say "complete rewrite"?) The discussion should focus on what happens as people become relatively satisfied with the core, and development shifts to optimizations, (smallish) bug fixes, and features that appeal to specialized audiences. That is when both the costs and the benefits of a tighter and/or time-based releases appear. > I was thinking something like doing a major release every 12 months > (rather than 18 to 24 months as has been heuristically the case > lately). This could also imply switching to some kind of loosely > time-based release system. I don't wish to express an opinion on either of these, as I'm not even in a position to help with release blockers. But I do hope discussion will focus on the implications for Python 3.7, not Python 3.3.
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