[IMPORTANT] post 3.7.0b1 development now open

Here we are: 3.7.0b1 and feature code freeze! Congratulations and thanks to all of you who've contributed to the huge number of PEPs, features, bug fixes, and doc changes that have gone into 3.7 since feature development began back in September 2016, after 3.6.0b1, 3.6's feature freeze. Now that feature development for 3.7 is over, the challenge is to put the finishing touches on the features and documentation, squash bugs, and test test test.
In the cpython repo, there is now a 3.7 branch. Starting now, all PRs destined for 3.7.0 should get cherry-picked from master to the 3.7 branch or just pushed to 3.7 if only applicable there. New features should continue to be pushed to the master branch for release in 3.8; no new features are now permitted in 3.7 unless you have contacted me and we have agreed on an extension (and all granted extensions will expire as of 3.7.0b2). As before, bug fixes appropriate for 3.6.x should continue to be cherry-picked to the 3.6 branch. I've updated the Developer's Guide to reflect the now current workflow. Let me know if you find any bugs in it. Likewise, please contact me if you have any questions about the workflow or about whether a change is appropriate for 3.7 beta.
The cpython repo on Github has been updated. You should now find that builds on the master branch produce a Python 3.8, rather than 3.7; you may want to clean your build directory. And there is now a 3.7 branch that you will need to use for 3.7 builds and pushs. There were several PRs that were merged to master over the last couple of days since we started 3.7.0b1 release engineering. All but one of those have been cherry-picked into the new 3.7 branch and you should have seen messages for them. One was for a 3.8 feature and so was not backported. At the moment, the new 3.7 buildbots may not be fully operational but they should be soon. Likewise, the docs.python.org may take up to 24 hours to reflect all the changes. Note that is the first time we've done a feature freeze using our new git-based workflow, so there's likely that there might be a glitch or something overlooked. Please let us know if you suspect something or have a question. I'll be around here and or #python-dev.
Also, don't forget to direct 3.8-related questions to Łukasz. Welcome on-board!
To recap:
2018-01-31: 3.7 branch open for 3.7.0; 3.8.0 feature development begins
2018-01-31 to 2018-05-21: 3.7.0 beta phase (no new 3.7 features)
- push PRs for new features, bugs, regressions, doc fixes to the master branch for release in 3.8
- cherry-pick or push PRs for 3.7.0 (bug/regression/doc fixes) to the new 3.7 branch
- cherry-pick or push select PRs for important bug/regression/doc fixes to 3.6 and 2.7 branches as appropriate
- propose PRs to 3.5 and 3.4 branches for any identified security issues
2018-02-26: 3.7.0 beta 2 (next beta preview)
2018-03-26: 3.7.0 beta 3 (3.7.0 ABI freeze)
2018-04-30: 3.7.0 beta 4 (only critical and urgent fixes after this point)
2018-05-21: 3.7.0 release candidate 1 (3.7.0 code freeze, only any emergency fixes afer this point)
2018-06-15: 3.7.0 release
2019-10-20: 3.8.0 release (next planned feature release, see PEP 569)
Thank you all again for your great efforts so far on 3.7!
--Ned

On 1/31/2018 8:04 PM, Ned Deily wrote:
In the cpython repo, there is now a 3.7 branch. Starting now, all PRs destined for 3.7.0 should get cherry-picked from master to the 3.7 branch or just pushed to 3.7 if only applicable there. New features should continue to be pushed to the master branch for release in 3.8; no new features are now permitted in 3.7 unless you have contacted me and we have agreed on an extension (and all granted extensions will expire as of 3.7.0b2). As before, bug fixes appropriate for 3.6.x should continue to be cherry-picked to the 3.6 branch. Should a patch for 3.6 be cherry-picked directly from master or from 3.7? Does it matter? With hg, double forward merges had to be done linearly, as from 3.6 to 3.7 and thence from 3.7 to 3.8 (master).

Should a patch for 3.6 be cherry-picked directly from master or from 3.7? Does it matter? With hg, double forward merges had to be done linearly, as from 3.6 to 3.7 and thence from 3.7 to 3.8 (master).
cherry_picker.py and miss-islington will backport from master to newest branch first. So master -> 3.7, then master -> 3.6, and master -> 2.7. It does not backport from 3.7 -> 3.6.
When doing it manually yourself, you should be able to backport from master -> 3.6 first and then master -> 3.7, it doesn't matter.
Mariatta Wijaya
participants (3)
-
Mariatta Wijaya
-
Ned Deily
-
Terry Reedy