On 05/12/2015 10:04 AM, Larry Hastings wrote:
What do you think? [...] Please cast your votes
workflow 012
Larry Hastings-0.5 10.5
Brett Cannon 010
Nick Coghlan 010
Chris Angelico 000“in favor of [Workflow 1]”
Ned Deily
Python 3.5 beta 1 is coming up soon. After beta is rc; after rc is
3.5.0 final. During the beta and rc periods the Python developer
workflow changes a little--what sorts of checkins are permissible, and
how to get something accepted and merged generally becomes more complicated.
I was
On Wed, May 13, 2015 at 3:04 AM, 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
On 05/12/2015 10:23 AM, Chris Angelico wrote:
Will this model be plausibly extensible to every release? For
instance, when a 3.5.1 rc is cut, will the 3.5 branch immediately
become 3.5.2, with a new 3.5.1 branch being opened on bitbucket?
Yes, we could always do it that way, though in the past
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
On 05/12/2015 10:04 AM, Larry Hastings wrote:
Workflow 1: +1
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
In article 55523adb.4000...@hastings.org,
Larry Hastings la...@hastings.org wrote:
On 05/12/2015 10:23 AM, Chris Angelico wrote:
Will this model be plausibly extensible to every release? For
instance, when a 3.5.1 rc is cut, will the 3.5 branch immediately
become 3.5.2, with a new 3.5.1
