Re: [Python-Dev] Status of 2.7 and 3.2
> I have thought that 2.7 was now to come out instead with 3.2 and would > include backported 3.2 new features. Others expect 2.7 to come out soon > after 3.1 and to only contain new 3.1 features. So Guido or someone, > please clarify: is 2.7 to be the counterpart of 3.1 or 3.2? Neither, nor. 2.7 will be released 18..24 months after 2.6, i.e. between April 2010 and October 2010. I think it's too early to speculate about a release schedule for 3.2. > 3.2 > > At some point, 3.x will become the "trunk" branch. It seems to me that > this should be done with 3.2 as part of the transition to Mercurial. I'm not sure that the concept of a "trunk" branch still exists in Mercurial. PEP 385 apparently doesn't have resolved the branch strategy for Mercurial yet. With cloned branches, I think the concept of a "trunk" becomes irrelevant. > A. As long as 2.x is 'trunk', some people will view 3.x as > 'experimental'. That was true for 3.0, but (much?) less so for 3.1. Is > there any known reason why 3.2 should not soon be considered and treated > as the main development version, to become the main production version? > > B. All new features will go into 3.2. Only some will be backported to > 2.x. So it seems that the flow should be to develop for 3.2 and maybe > backport thereafter. What about bug fixes? How will they flow? > 2.final > > Is there any thought of making 2.7 be 2.final? Yes. Whether or not a 2.8 release will happen hasn't been decided yet, but 2.7 may well be the last 2.x release. > B. Do we really want to encourage library developers to put their > 'upgrade to a new version' energy into 2.x to 2.x+1 upgrades, rather > than a 2.x to 3.y upgrades? IMO, it's much up to the contributors. If the regular committers want to continue to work on 2.x, and a release manager is found to create releases, we can continue to release 2.8, and perhaps 2.9. However, I think at this point, it is too early to discuss that - 2.7 is still many months ahead. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 2.7 and 3.2
"Martin v. Löwis" writes: > I'm not sure that the concept of a "trunk" branch still exists in > Mercurial. PEP 385 apparently doesn't have resolved the branch strategy > for Mercurial yet. With cloned branches, I think the concept of a > "trunk" becomes irrelevant. "Trunk" exists as a technical restriction in CVS, and maybe to some extent in Subversion. Of course that restriction is lifted by DVCSes. But really "trunk" is a social concept. Most projects have a trunk. Even the anarchy known as GNU Arch converged on Tom Lord's version, just as the storm of turbulance known as "Linux kernel development" does on Linus's. Python's 2.x/py3k division is a tour de force; I still can't believe my eyes that you've pulled it off. Consider Perl 6, LaTeX 3, and Zope 3, or Linux 3, for that matter. The first 3 are all facing the "what is trunk?" issue, in the case of Zope several years after the "point oh" release, and AFAIK there are no current plans for Linux 3 (a microkernel architecture, maybe?<1.01 wink>). Of course the issues faced by LaTeX, Zope, and the kernel are quite different from Python's, and I don't know enough about Perl internals to compare. So I think "trunk" does matter. But it's not entirely in the power of the Python committers, not even the BDFL, to determine what "trunk" is. > Terry Reedy writes: > > A. As long as 2.x is 'trunk', some people will view 3.x as > > 'experimental'. That was true for 3.0, but (much?) less so for 3.1. Is > > there any known reason why 3.2 should not soon be considered and treated > > as the main development version, to become the main production version? Yes. User/developers may prefer strongly prefer the stability of 2.x. That's the problem of being a successful product, you lose agility almost by definition. > > B. All new features will go into 3.2. Only some will be backported to > > 2.x. So it seems that the flow should be to develop for 3.2 and maybe > > backport thereafter. > > What about bug fixes? How will they flow? This has to be ad hoc, at least at first. Some bugs will be uncovered in each version. The solutions will often not be the same in the different versions. Many developers will be downstream, and only willing to contribute the patch for the version they use. > > B. Do we really want to encourage library developers to put their > > 'upgrade to a new version' energy into 2.x to 2.x+1 upgrades, rather > > than a 2.x to 3.y upgrades? > > IMO, it's much up to the contributors. I think so, too. Terry's word "encourage" is appropriate here, though, and at some point that question will need to be answered. I think he's right to raise it early. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 2.7 and 3.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen J. Turnbull wrote: > "Martin v. Löwis" writes: > > > I'm not sure that the concept of a "trunk" branch still exists in > > Mercurial. PEP 385 apparently doesn't have resolved the branch strategy > > for Mercurial yet. With cloned branches, I think the concept of a > > "trunk" becomes irrelevant. > > "Trunk" exists as a technical restriction in CVS, and maybe to some > extent in Subversion. Of course that restriction is lifted by DVCSes. > > But really "trunk" is a social concept. Most projects have a trunk. > Even the anarchy known as GNU Arch converged on Tom Lord's version, > just as the storm of turbulance known as "Linux kernel development" > does on Linus's. > > Python's 2.x/py3k division is a tour de force; I still can't believe > my eyes that you've pulled it off. Consider Perl 6, LaTeX 3, and Zope > 3, or Linux 3, for that matter. The first 3 are all facing the "what > is trunk?" issue, in the case of Zope several years after the "point > oh" release, and AFAIK there are no current plans for Linux 3 (a > microkernel architecture, maybe?<1.01 wink>). Of course the issues > faced by LaTeX, Zope, and the kernel are quite different from > Python's, and I don't know enough about Perl internals to compare. FWIW, it seems to be consensus in the Zope community that "Zope3" was a misnomer, reflecting a vision for the software (serving as the replacement / successor to Zope2) which it didn't grow to fulfill. At this point, the "reusable" bits now form a collection of separately-released packages referred to as the "Zope Toolkit,"[1] which is intended to be used by Zope2, Grok, and the folks still running the "pure" Zope3 appserver. A lot of the work involved in this effort has been in disentagling the dependencies among the various packages, precisely so that they can be used piecemeal, without pulling in all of the stack. [1] http://docs.zope.org/zopetoolkit/ Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKK7px+gerLs4ltQ4RAoMnAJ9WTL8zo3+bSop+SAXr+akp85tMZQCfS5oC y14j64VJPjgxDQzCb1p/iZo= =RCZa -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 2.7 and 3.2
Martin v. Löwis wrote: >> I have thought that 2.7 was now to come out instead with 3.2 and would >> include backported 3.2 new features. Others expect 2.7 to come out soon >> after 3.1 and to only contain new 3.1 features. So Guido or someone, >> please clarify: is 2.7 to be the counterpart of 3.1 or 3.2? > > Neither, nor. 2.7 will be released 18..24 months after 2.6, i.e. between > April 2010 and October 2010. I think it's too early to speculate about > a release schedule for 3.2. I think Terry's underlying question is more basic than that. It can also be phrased as: "Is 2.7 allowed to have new features which did not appear in 3.1?" In previous discussions, a general policy has been articulated that having released Python 3.0, any new features should appear in a 3.x release before they appear in a 2.x release. Following that policy (which I think is actually a good one) means there are certain consequences for the two possible answers to the above question: A. "No." This answer means that 2.7 will only contain new features that are part of 3.1. If 2.7 sticks to a normal 18-24 month release cycle the only activities on the trunk for the next 12 months or so should be backports from 3.1 and bug fixes. New features added to the py3k branch for 3.2 should not be backported until after 2.7 is released. The other alternative in this case is to release 2.7 earlier than normal, but that creates problems in terms of the absolute duration of maintenance branch support for 2.6. B. "Yes." This answer means that the 3.1 to 3.2 development cycle will need to be truncated by roughly 6 months so that 3.2 can be released before 2.7 with any new features of interest. The 3.2 and 2.7 releases should then occur within a few months of each other. Releasing 2.7 early doesn't seem like a good idea to me and neither does putting the trunk into the equivalent of a feature freeze for 12 months or more. So I'm in favour of the idea of a paired 3.2/2.7 release late next year. I don't think that's a novel idea though - I'm pretty sure it was suggested (and met with general approval) when the idea of a short release cycle for 3.1 was first brought up. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 2.7 and 3.2
Nick Coghlan wrote: > Martin v. Löwis wrote: >>> I have thought that 2.7 was now to come out instead with 3.2 and would >>> include backported 3.2 new features. Others expect 2.7 to come out soon >>> after 3.1 and to only contain new 3.1 features. So Guido or someone, >>> please clarify: is 2.7 to be the counterpart of 3.1 or 3.2? >> Neither, nor. 2.7 will be released 18..24 months after 2.6, i.e. between >> April 2010 and October 2010. I think it's too early to speculate about >> a release schedule for 3.2. > > I think Terry's underlying question is more basic than that. It can also > be phrased as: > > "Is 2.7 allowed to have new features which did not appear in 3.1?" I don't think this is the question Terry meant to ask, and the answer to this question is a clear "Certainly, but you are asking the wrong question." The question that Terry really meant to ask is "why is there no release candidate for 2.7 already, when 3.1 is going to be released RSN?", and that question arises from the (incorrect) understanding that 2.x releases and 3.x releases will be lock-step. The question that you posed should have been phrased as "Is 2.7 allowed to have new features which don't also appear on the 3k branch?", to which the answer is a clear "No." > In previous discussions, a general policy has been articulated that > having released Python 3.0, any new features should appear in a 3.x > release before they appear in a 2.x release. I don't think that the policy has been articulated in exactly that way, and it certainly wasn't implemented for 2.6/3.0. 2.6 was released with features that had not been released in any 3.x release, just because 3.x had not been released at all. > A. "No." > > This answer means that 2.7 will only contain new features that are > part of 3.1. If 2.7 sticks to a normal 18-24 month release cycle the > only activities on the trunk for the next 12 months or so should be > backports from 3.1 and bug fixes. New features added to the py3k branch > for 3.2 should not be backported until after 2.7 is released. The other > alternative in this case is to release 2.7 earlier than normal, but that > creates problems in terms of the absolute duration of maintenance branch > support for 2.6. I think this makes it clear that the answer can't possibly be "No". Not allowing addition of new features even though the release is still 12 months away would be unreasonable, IMO - what's the point of freezing development now, and where should new features to 2.x be added if not to the trunk? Likewise, releasing 2.7 now is completely unacceptable. > B. "Yes." > > This answer means that the 3.1 to 3.2 development cycle will need to > be truncated by roughly 6 months so that 3.2 can be released before 2.7 > with any new features of interest. The 3.2 and 2.7 releases should then > occur within a few months of each other. Assuming the policy "release new features for 2.x only after they got released for 3.x". I don't think such a policy actually exists. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 2.7 and 3.2
On Sun, 7 Jun 2009 at 18:55, "Martin v. L?wis" wrote: B. "Yes." This answer means that the 3.1 to 3.2 development cycle will need to be truncated by roughly 6 months so that 3.2 can be released before 2.7 with any new features of interest. The 3.2 and 2.7 releases should then occur within a few months of each other. Assuming the policy "release new features for 2.x only after they got released for 3.x". I don't think such a policy actually exists. I'm neutral on time frames, but I think that it _should_ be a policy that new features only get released to the 2.x branch after they have been released in the 3.x branch. Or, rather, I though that policy was implicit in the idea that we weren't _automatically_ backporting features, specifically in order to encourage 3.x adoption. So if 2.7 is going to come out before 3.2, you'll have to convince me that having new features in 2.7 that aren't in 3.1 is a good idea :) Note that I'm not advocating feature freezing the trunk, but rather having 3.2 come out before or in sync with 2.7. --David___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 2.7 and 3.2
> I'm neutral on time frames, but I think that it _should_ be a policy > that new features only get released to the 2.x branch after they have > been released in the 3.x branch. Or, rather, I though that policy was > implicit in the idea that we weren't _automatically_ backporting features, > specifically in order to encourage 3.x adoption. I think "backporting" is an entirely different issue, let alone "automatic" backporting. What *is* policy (AFAIU) is "any feature in the trunk must also exist in the py3k branch". IMO, this is sufficient to encourage 3.x adoption, and it is a policy that is silent wrt. to release date ordering. 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. > So if 2.7 is going to > come out before 3.2, you'll have to convince me that having new features > in 2.7 that aren't in 3.1 is a good idea :) I don't see why the precise ordering of release dates matters at all. It seems you are happy with having 3.2 be released "around the same time" as 2.7. What is "the same time"? 3 months difference? 6 months difference? It certainly wouldn't be a year. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 2.7 and 3.2
On Jun 7, 2009, at 12:55 PM, Martin v. Löwis wrote: Assuming the policy "release new features for 2.x only after they got released for 3.x". I don't think such a policy actually exists. The policy, as I remember it, can be summed up: don't innovate new features in the 2.x branch. Meaning, add it to 3.x first and then backport if you want. I don't believe a new feature has to be in a / released/ version of 3.x first for it to show up in the next 2.x release. -Barry PGP.sig Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 2.7 and 3.2
On Sun, 7 Jun 2009 at 21:21, "Martin v. L?wis" wrote: I'm neutral on time frames, but I think that it _should_ be a policy that new features only get released to the 2.x branch after they have been released in the 3.x branch. Or, rather, I though that policy was implicit in the idea that we weren't _automatically_ backporting features, specifically in order to encourage 3.x adoption. I think "backporting" is an entirely different issue, let alone "automatic" backporting. What *is* policy (AFAIU) is "any feature in the trunk must also exist in the py3k branch". IMO, this is sufficient to encourage 3.x adoption, and it is a policy that is silent wrt. to release date ordering. You are right, my use of the term backport was imprecise. My impression at pycon was that Guido (and others) wanted a stronger policy than "make sure new features in trunk are also in 3.x". I heard this as "put new features in 3.x, not 2.x, to encourage 3.x adoption," but leaving the decision to the individual developers on whether or not to also "backport" them to 2.x. (The quotes around backport being that if you know you are going to put it into both it is currently easier to do trunk first.) As we have discovered since, this tends to get modified by wanting to ease transition from 2.x to 3.x by providing some of the features in 2.x (I'm thinking specifically of the distutils discussion.) How I got from that to release date ordering was by hearing that as "new features should be in 3.x first, and only maybe in 2.x". Clearly that was just my interpretation :) 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. So if 2.7 is going to come out before 3.2, you'll have to convince me that having new features in 2.7 that aren't in 3.1 is a good idea :) I don't see why the precise ordering of release dates matters at all. It seems you are happy with having 3.2 be released "around the same time" as 2.7. What is "the same time"? 3 months difference? 6 months difference? It certainly wouldn't be a year. No more than three months, I'd say, but that's just a gut level feeling, not backed by a specific argument. That said, I also have a gut level feeling that it is better to have the new features come out in 3.2 _first_. But I'm not presenting that as anything more than my feeling, and I'm happy to go with whatever consensus develops. FWIW, Benjamin has said the he personally has no problem with 3.2's release cycle being shorter than "normal". --David___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 2.7 and 3.2
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 2.7 and 3.2
2009/6/7 Michael Foord : > 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. And that's what we want to avoid, so we are discussing 3.2. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 2.7 and 3.2
Nick Coghlan wrote: Martin v. Löwis wrote: I have thought that 2.7 was now to come out instead with 3.2 and would include backported 3.2 new features. Others expect 2.7 to come out soon after 3.1 and to only contain new 3.1 features. So Guido or someone, please clarify: is 2.7 to be the counterpart of 3.1 or 3.2? Neither, nor. 2.7 will be released 18..24 months after 2.6, i.e. between April 2010 and October 2010. I think it's too early to speculate about a release schedule for 3.2. I think Terry's underlying question is more basic than that. It can also be phrased as: "Is 2.7 allowed to have new features which did not appear in 3.1?" That is the issue that came up in a Python list discussion when two people, including one who I expect to know as much as me about this, 'corrected' my 'yes' to "No, 2.7 will come out in a few months after 3.1." So there clearly is confusion on this and related issues (as I already see in the responses on this thread ;-). The answer makes some difference in how issues are handled on the tracker, which I occasionally help with. In previous discussions, a general policy has been articulated that having released Python 3.0, any new features should appear in a 3.x release before they appear in a 2.x release. Following that policy (which I think is actually a good one) means there are certain consequences for the two possible answers to the above question: A. "No." This answer means that 2.7 will only contain new features that are part of 3.1. If 2.7 sticks to a normal 18-24 month release cycle the only activities on the trunk for the next 12 months or so should be backports from 3.1 and bug fixes. New features added to the py3k branch for 3.2 should not be backported until after 2.7 is released. The other alternative in this case is to release 2.7 earlier than normal, but that creates problems in terms of the absolute duration of maintenance branch support for 2.6. I agree, but this is what two people are expecting. B. "Yes." This answer means that the 3.1 to 3.2 development cycle will need to be truncated by roughly 6 months so that 3.2 can be released before 2.7 with any new features of interest. The 3.2 and 2.7 releases should then occur within a few months of each other. Releasing 2.7 early doesn't seem like a good idea to me and neither does putting the trunk into the equivalent of a feature freeze for 12 months or more. So I'm in favour of the idea of a paired 3.2/2.7 release late next year. This is what I have been expecting, I don't think that's a novel idea though - I'm pretty sure it was suggested (and met with general approval) when the idea of a short release cycle for 3.1 was first brought up. I presume because it has been stated before. In addition to the question above, I am also trying to provoke thought on the nature and purpose of 2.7. Backporting features 'if someone feels like it' seems pretty haphazard. For someone wanting to maintain compatibility across multiple 2.x releases, a random new features may be nearly useless. Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 2.7 and 3.2
Terry Reedy wrote: [snip...] I don't think that's a novel idea though - I'm pretty sure it was suggested (and met with general approval) when the idea of a short release cycle for 3.1 was first brought up. I presume because it has been stated before. In addition to the question above, I am also trying to provoke thought on the nature and purpose of 2.7. Backporting features 'if someone feels like it' seems pretty haphazard. For someone wanting to maintain compatibility across multiple 2.x releases, a random new features may be nearly useless. The "What's new in Python 2.7" list is already very impressive. :-) Michael Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 2.7 and 3.2
On Sun, 7 Jun 2009 at 21:55, Michael Foord wrote: 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. As I said on IRC, that's not what I'm advocating. I'm advocating having 3.2 come out before 2.7, so that the new post-3.1 features get released to the public in 3.2 first, before appearing in 2.7. (Although "first" could alternatively mean the same day, if the community were up to for that). But like I said I'm not attached to the idea, just advocating it ;) --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 2.7 and 3.2
How about we just continue to improve both branches, doing forward or backports as appropriate. No need to develop a policy of crippling one branch on the theory that it will make the other seem more attractive. Besides, if 2.7 and 3.2 get released within a few months of each other, any inversion of incentives will be temporary and fleeting. Most likely people's decisions on switching to 3.x will be dominated by other factors such as the availability of third-party modules or other dependencies. IIRC, Benjamin's current merge procedures flow from the trunk to the py3k branch. Probably, it is best to continue with that practice lest we muck-up his merge/block entries. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 2.7 and 3.2
Martin v. Löwis wrote: > I don't think that the policy has been articulated in exactly that > way, and it certainly wasn't implemented for 2.6/3.0. 2.6 was released > with features that had not been released in any 3.x release, just > because 3.x had not been released at all. I don't think the idea of "3.x first" was raised explicitly until the discussions about having a short release cycle for 3.1 came up. Before then there was an assumption that 3.1 and 2.7 would come out at roughly the same time. >> B. "Yes." >> >> This answer means that the 3.1 to 3.2 development cycle will need to >> be truncated by roughly 6 months so that 3.2 can be released before 2.7 >> with any new features of interest. The 3.2 and 2.7 releases should then >> occur within a few months of each other. > > Assuming the policy "release new features for 2.x only after they got > released for 3.x". I don't think such a policy actually exists. As RDM already mentioned, the potential problem such a policy is intended to address is the idea of being able to write 2.7 code that can't be forward ported to 3.x because no version with a corresponding feature set has been released yet. My last sentence above was actually deliberately ambiguous as to whether 2.7 or 3.2 ends up being released first - so long as the releases happen within a few months of each other and any new features that appear in 2.7 also appear in 3.2, then the migration path for different 2.x versions remains clear (i.e 2.6-only code can be migrated to 3.1, but 2.7 code may need to be migrated to 3.2 instead if it uses features that aren't in 3.1). The exact order and timing of 3.2/2.7 will no doubt depend on any specific issues relating to the two releases around the time that they come out. But in the interests of maintaining a coherent migration path from 2.x to 3.x, it makes sense to plan to release them at roughly the same time. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of 2.7 and 3.2
Raymond Hettinger wrote: > How about we just continue to improve both branches, doing forward or > backports as appropriate. No need to develop a policy of crippling > one branch on the theory that it will make the other seem more > attractive. > > Besides, if 2.7 and 3.2 get released within a few months of each > other, any inversion of incentives will be temporary and fleeting. > Most likely people's decisions on switching to 3.x will be dominated > by other factors such as the availability of third-party modules or > other dependencies. > > IIRC, Benjamin's current merge procedures flow from the trunk to the > py3k branch. Probably, it is best to continue with that practice > lest we muck-up his merge/block entries. Agreed. >From Terry's later response, I think the main confusion here was whether or not 2.7 was going to be getting released hot on the heels of 3.1, and the answer to that is "No, 2.7 won't be released until 18-24 months have passed since the release of 2.6, as with previous 2.x releases". Releasing 3.2 around the same time as 2.7 to allow for easier migration from the latest 2.x release to the latest 3.x release will likely make sense, but doesn't actually need to be a 100% definite plan at this point. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
