[Python-Dev] Python 3.4: Cherry-picking into rc2 and final
larry at hastings.org
Mon Feb 17 00:25:52 CET 2014
Right now we're in the "release candidate" phase of 3.4. 3.4.0 rc1 has
been released, and the next release will be rc2.
You might think that anything you check in to the "default" branch in
Python trunk will go into 3.4.0 rc2, and after that ships, checkins
would go into 3.4.0 final. Ho ho ho! That's not true! Instead,
anything checked in to "default" between my last revision for "rc1"
(e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only
fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and
final. And my local branch will remain private until 3.4.0 final ships!
If you have a Terribly Important Fix That Must Go Into 3.4.0 rc2 or
final, please go to the issue tracker and create a new issue with the
The title should start with "3.4 cherry-pick: " followed by the
revision id and a short summary
example: "3.4 cherry-pick: b328f8ccbccf __getnewargs__ fix"
The version should be "Python 3.4"
The assignee should be "larry"
The priority should be "release blocker"
The comment should *also* contain the revision id (the tracker will
turn it into a link)
I'm also working on automatically publishing the merged/unmerged
revision status to a web page. You can see a mock-up here:
The page is marked "beta" because it doesn't have real data yet--I'm
still experimenting with my automation, so I haven't created the real
3.4 local branch yet. Again, just to be crystal-clear: the revisions
marked "merged" on that page are just experiments, they aren't actually
merged for 3.4. Once I'm ready for real merging, I'll remove the beta
(By the way: on that page, clicking on a revision takes you to the
revision web page. Clicking on the first line of the comment expands it
to show the complete comment.)
Please use your best judgment before asking that a revision be
cherry-picked into 3.4.0. Our goal in the release candidate phase is to
stabilize Python, and to do that we must stop changing it. Only
important interface changes, new features, or bugfixes should be checked
in now, and preferably they should be low-risk.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev