On 29 Oct, 09:14 pm, amk at amk.ca wrote: >Will 3.1 and 2.7 also be parallel releases? (I ask, not having read >the 3xxx PEPS at all.) > >If yes, why? While I can see a case for 2.6/3.0 being in sync -- new >features in 2.6 ease the transition to 3.0 -- I'd imagine that 3.1 >would be better with a shorter cycle (6-9 months) because there are >more possible rough edges to clean up. 3.1 would likely include >bugfixes from the eventual 2.7, so 3.1 might also trigger 2.6.1, but I >don't think there's any harm if 3.1 contains features or incompatible >fixes that are unavailable to 2.x users. 2.7 is where a new version of 2to3 will be distributed. As people actually start trying to migrate real-world code, lots of issues are inevitably going to be discovered there. From my perspective, 2.7 and 3.1 need to be synced because 2.7 is the tool that will actually enable users of existing code to *use* 3.1. And this isn't just about a release of the 2to3 tool itself, but fixes in the 2.x backports of various stdlib features to deal with the kinds of parity issues that users are only going to discover in large-scale, real-world testing.
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