R. David Murray wrote: > [snip...] >> By the policy you propose, we could not have released 2.6 in October >> 2008, which we really really wanted to because Apple wanted us to. > > I don't think the 2.6 release date is relevant to this discussion, > since 3.x hadn't been released at all at that point. What I want to > avoid is people writing new code for 2.7 instead of 3.1 because they > want to take advantage of a nifty new feature that 3.1 doesn't have. > But 3.1 is in feature freeze (py3k trunk) and it is not possible to check-in code for 3.2. Following this policy it would mean a feature freeze on trunk for an indefinite period of time. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
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