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

[Chris Angelico]

On Wed, May 13, 2015 at 3:04 AM, 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.
>

As a non-core-dev, I would be in favour of this model. I use the
CPython trunk as my build branch for "give me the absolute latest
CPython", and this means that that will always be the case. Same with
the 3.5 branch always meaning "the absolute latest CPython 3.5".
Whether the 3.5.0 branch is on the main hg.python.org or bitbucket
makes no difference to me, as I wouldn't be building against it, so do
whatever makes sense for you and the core dev team. Testing a patch
off the issue tracker would normally want to be done on trunk, I
presume.

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?

This model seems the easiest to explain. Every branch is the latest of
whatever it describes; to access anything earlier, including proposed
versions, you seek a different branch.

ChrisA