On May 12, 2015, at 10:04, Larry Hastings <la...@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 n...@acm.org -- [] _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
