Terry Reedy wrote: > Nick Coghlan wrote: >> Terry Reedy wrote: >>>>> As for the actual feature, I don't think it should hold up releases. >>>> Fair enough. >>> Given that the purpose of 2.7 is >>> a) maintenance of existing code (which can include minor new features >>> for existing facilities), and >>> b) easing conversion of code to 3.1 >>> I am puzzled at the idea of adding a new facility to 2.7 that would not >>> be in 3.1+. It would lock code into 2.7+ and counter purpose b). >> >> It's possible we will end up in a situation where 3.0 and 3.1 are both >> aligned with 2.6, while 2.7 aligns with 3.2. That's particularly so with >> only 6 months or so between 3.0 and 3.1, while I currently expect the >> gap between 2.6 and 2.7 to be closer to the traditional 18 months. > > OK, that suggests that the new feature should only be committed, if > ever, to 2.7 after 3.1, when it can also be committed to 3.2 at the same > time.
Not really - there's already stuff in 3.0 that wasn't backported the first time around. I suspect the discrepancy here relates to different views on the purpose of future 2.x releases. I would demote your two points above to be goals b) and c) and give its primary purpose as: a) Provide an updated 2.x compatible release with new features for the benefit of those not yet able to make the transition to the 3.x series. Some of those new features will be additional 3.x series backports, some of them will be new features that were added to both 2.x and 3.x at the same time. The only thing that I believe *shouldn't* happen is for 2.7 to be released with new features that aren't yet available in a 3.x release. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
