[Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!) (original) (raw)

Ned Deily nad at acm.org
Tue May 12 19:23:47 CEST 2015

On May 12, 2015, at 10:04, Larry Hastings <larry at hastings.org> wrote:

Workflow 1 ==========

When I ship beta 1, we create the 3.5 branch. trunk become 3.6. When I ship rc 1, the 3.5 branch becomes 3.5.1. I maintain a publically visible repo on bitbucket for 3.5.0, and we use bitbucket "pull requests" for cherry-picks from 3.5.1 into 3.5.0. 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.

One possible issue with Workflow 1 is that there would need to be an additional set of buildbots (for 3.5, in addition to the existing 3.x (AKA "trunk"), 3.4, and 2.7 ones) for the period from beta 1 until at least 3.5.0 is released and, ideally, until 3.4 support ends, which following recent past practice, would be relatively soon after 3.5.0.

Workflow 2 ==========

When I ship beta 1, trunk remains 3.5. 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.

Where does 3.6.x fit into Workflow 2?

-- Ned Deily nad at acm.org -- []

More information about the Python-Dev mailing list