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

[Ned Deily]

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 -- []