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

Antoine Pitrou solipsis at pitrou.net
Tue May 12 19:53:13 CEST 2015

On Tue, 12 May 2015 10:04:39 -0700 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.

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.

More information about the Python-Dev mailing list