Defer creating 3.8 branch until 3.8.0rc1?

There are less than two months until Python 3.8.0b1.

Conventionally, we had created branch for version when beta1 is released.
But we has focused fixing bugs, rather than implementing new thing after beta.

How about create 3.8 branch when 3.8.0rc1, not 3.8.0b1?
I think there are two benefits:

Reducing backport cost

About 6/7 commits in master branch were backported to beta branch.
Backporting is easier than before (thank you, Mariatta!). But it still take some efforts.

$ git log --first-parent --oneline v3.7.0b1..v3.7.0rc1 | wc -l
$ git log --first-parent --oneline --since="2018-01-30" --until="2018-06-12" | wc -l

Simpler changelog

There are many duplicated changelog entries in .

For example, bpo-28183 is listed in “3.7.0 alpha 1” and " 3.6.0 beta 2".
It makes reading changelog little harder.

We can reduce duplicated changelog in “3.9.0 alpha 1” by defer creating 3.8 branch until 3.8rc1.

Of course, there are downsides.

We need to “freezing” window. No pull requests for new features must not be merged between 3.8b1 and 3.8rc1. It will be frustrating, especially for new contributors.

As far as I know, Go uses this approach. They have 6 months release cycle. And there is about 3 months “release freeze”. Go Release Cycle

In our case, there are about 4 months between beta1 and rc1. It is longer than Go’s “release freeze”.

How do you think?

Conventionally, we had created branch for version when beta1 is released.

That’s actually a fairly recent innovation; I believe 3.5 was the first release where we created the release branch at feature code cutoff (beta 1) time rather than at rc time. We explicitly made this change in process after discussion of alternatives and the clear favorite was to allow feature development to continue in parallel with the stabilization of the next release unlike what we had done in the past. See the thread starting at I believe we have also discussed this workflow at more than one Language Summit.

So here you’re essentially proposing to return to how we did things prior to 3.5. Having seen both ways (pre-3.5 and 3.5+), I am convinced that the way we do things now is superior - especially now that the semi-automated backport merging between branchs under our current Github-based workflow is so much more easy than the manual forward porting that we did previously (and that was used for 3.5). So I would very much not be in favor of making such a change.

Regarding changelog entries, that’s really a separate and resolvable issue and should not be used as a reason to make a change in our development process. The way we handle overlaps between release changelogs is less than ideal at the moment and needs some attention as part of release management. It’s on my list of things to look at and propose a solution. But in the greater scheme of things, it’s a pretty minor issue.


You’re right. It’s essentially same. There is small difference (feature freeze ends at rc1), but it’s only one month difference.

Personally, I had not committed large change which can make backport difficult during 3.6.0beta1 and 3.6.0rc1. I think others focus fixing bugs in beta period and not commit large change in master branch too. So backport must be easy.

I see.

I also prefer the current system to the previous system. New feature freezes were an occasional nuisance.

1 Like