<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
Python 3.5 beta 1 is coming up soon. After beta is rc; after rc is
3.5.0 final. During the beta and rc periods the Python developer
workflow changes a little--what sorts of checkins are permissible,
and how to get something accepted and merged generally becomes more
complicated.<br>
<br>
I was the release manager for Python 3.4, and the way I ran the rc
period for 3.4 was miserable. Everyone hated it--and that includes
me. I'm absolutely not doing it that way for 3.5. But that leads
one to the question: okay, how *am* I going to run it? I have three
ideas for workflows for the beta and rc periods for 3.5, below. But
first let's talk about what I/we hope to achieve.<br>
<br>
Traditionally during the beta and rc periods, development of new
features stops completely. Obviously, after feature freeze no new
features can go into the beta / rc releases. But why can't people
develop new features for the *next* release? The reason given is
that we're trying to guide the core dev community in the right
direction--they should concentrate on fixing bugs in the new
release. I suspect the real reason for this is that back in the bad
old days of Subversion (and CVS!) branching and merging were
painful. This social engineering policy is a justification
after-the-fact.<br>
<br>
But Mercurial makes branching and merging nearly effortless.
Mercurial also makes it painless to develop new features in
private. So consider: anyone who wants to work on new features
during beta and rc can easily do so. All our "no new features
during beta and rc" policy really does is drive such development
away out of public view.<br>
<br>
I think it's time we experimented with lifting that policy. The
trick is finding a good place for us to check in the work. You see,
during the 3.5 rc period, we arguably want to accept checkins for
*three* different revisions:<br>
<blockquote>3.5.0<br>
3.5.1<br>
3.6<br>
</blockquote>
3.5.1? Yep. During the rc period for 3.4--and particularly after
the last rc was tagged--there were a lot of minor fixes that were
desirable, but I didn't want to accept into 3.4 just to avoid
destabilizing the release. I still wanted those checkins, I just
didn't want them in 3.4.0. So the way it worked was, developers
would check those bugfixes in to trunk, then I'd cherry-pick the
revisions I wanted into the rc branch. In other words, during the
rc period for 3.4, trunk effectively represented 3.4.1. This was
valuable and I absolutely want to do it again.<br>
<br>
<br>
So here are the workflows. Workflow 0 most resembles what we've
done in the past. Workflow 1 is my favorite and the most
ambitious. All three give us a public place to put revisions for
3.5.0 and 3.5.1; Workflow 1 also gives us a place to check in work
for 3.6 during the beta and rc periods for 3.5. Workflow 2 is a
less ambitious compromise.<br>
<br>
<br>
Workflow 0<br>
==========<br>
<br>
When I ship beta 1, trunk remains 3.5.<br>
<br>
When I ship rc 1, trunk becomes 3.5.1. I create a publically
visible read-only repo that represents 3.5.0, and any checkins that
I want to accept into 3.5.0 I must manually cherry-pick from trunk.<br>
<br>
When I ship Python 3.5.0 final, we branch 3.5, and trunk becomes
3.6.<br>
<br>
Workflow 1<br>
==========<br>
<br>
When I ship beta 1, we create the 3.5 branch. trunk become 3.6.<br>
<br>
When I ship rc 1, the 3.5 branch becomes 3.5.1. I maintain a
publically visible repo <i>on bitbucket</i> for 3.5.0, and we use
bitbucket "pull requests" for cherry-picks from 3.5.1 into 3.5.0.<br>
<br>
This gives us a pilot project to try out a web GUI for merging. It
makes my workflow easier, as I can push a button to accept
cherry-picks. (If they don't apply cleanly I can tell the author to
go fix the conflict and resubmit it.) The downside: it requires
core devs to have and use bitbucket accounts.<br>
<br>
Workflow 2<br>
==========<br>
<br>
When I ship beta 1, trunk remains 3.5.<br>
<br>
When I ship rc 1, we create the 3.5 branch. The 3.5 branch is 3.5.0
and trunk is 3.5.1. Only blessed stuff gets cherry-picked from
3.5.1 back into 3.5.0.<br>
<br>
<br>
What do you think? My votes are as follows:<br>
<blockquote>Workflow 0: -0.5<br>
Workflow 1: +1<br>
Workflow 2: +0.5<br>
</blockquote>
<br>
Please cast your votes,<br>
<br>
<br>
<i>/arry</i><br>
</body>
</html>