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
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
