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