[Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
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?
nad at acm.org -- 
More information about the Python-Dev