On Tue, 12 May 2015 10:04:39 -0700 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.
Only if they want to submit cherry-picks, of course. > What do you think? My votes are as follows: > > Workflow 0: -0.5 > Workflow 1: +1 > Workflow 2: +0.5 > > Please cast your votes, Well, since you're the one doing the work, and you seem to be ok with the most complicated workflow, I'll vote exactly as you :) Another entirely different approach, though, is to rework the release cycle and shorten the time between feature releases. Then we can have shorter freeze periods (the current freeze durations are really long). Regards Antoine. _______________________________________________ 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
