I was reviewing some PRs that had new parameters introduced in the API. Since 3.8 beta 1 will be released in a month I am curious what is the scope of merging small enhancements or API changes. Does a feature freeze means only large changes like PEP implementations will not be merged or does any small enhancement with some behavior change or API additons/change/removals will not get merged? In case of latter one does that mean 3.8 branch will act like 3.7 that receives only bug fixes for features already merged before beta during the course of beta and RC with master used for next release as 3.9 dev?
Is there a scope on what would go after 3.8 beta 1 or is it up to the release manager to decide whether these enhancements and API changes can be merged to 3.8?
@ambv has the final word for 3.8 but, in the recent past, we have tried to follow the process documented in the Dev Guide for the beta stage:
After a first beta release is published, no new features are accepted. Only bug fixes can now be committed. This is when core developers should concentrate on the task of fixing regressions and other new issues filed by users who have downloaded the alpha and beta releases.
Being in beta can be viewed much like being in RC but without the extra overhead of needing commit reviews.
Of course, when necessary, exceptions to the policy are negotiable.
Thanks @nad for the link. Given that there had been a core dev sprint just before the beta release in the past I guess there are more features pushed during the sprint with PyCon sprint up next month. Also since decision on some PEPs were deferred due to governance during the 3.8 cycle there might be some overhead for the RM in stabilizing the builds for release and the policy makes sense to have only bug fixes done.