[Python-Dev] Python 3.4: Cherry-picking into rc2 and final

Larry Hastings 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 
following attributes:

    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...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140216/ad7941a3/attachment.html>

More information about the Python-Dev mailing list