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 "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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
