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

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).



More information about the Python-Dev mailing list