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

Chris Angelico rosuav at gmail.com
Tue May 12 19:23:38 CEST 2015

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

More information about the Python-Dev mailing list