[python-committers] Extending 3.6 [was: 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!] (original) (raw)

Ned Deily nad at python.org
Wed Dec 19 14:38:45 EST 2018

On Dec 19, 2018, at 04:14, Serhiy Storchaka <storchaka at gmail.com> wrote:

Can we revise our policy and prolong the bug fixing mode for 3.6? 3.6 is the default Python in Ubuntu 18.04 LTS and RHEL 8. And due to several important syntax features it can be a minimal required version for long time.

We could but we are not going to now for multiple reasons.

I merged several PRs before releasing 3.6.8rc1, but there are still less trivial bugfix PRs which need more time for reviewing, and there are bugs for which no PR is created yet. There is also a number of documentation PRs. I propose to allow backporting bugfixes to 3.6 if they do not need excessive work, but stop to fix 3.6 only bugs. After migrating to GitHab, backporting became less painful, most of backports to 3.6 can be done automatically from master or from 3.7.

There are always going to be bugs that remain unfixed when a release branch moves from bugfix mode to security-fix only mode. That has been true for all previous Python branches.

So what, if anything, is different about 3.6?

I see two possibly significant differences:

What hasn't changed in 3.6?

So, extending the bugfix support window of a release affects and is asking for significant commitments from core developers, release teams, infrastructure support, third-party users and distributors. It is not something to be taken lightly - especially when most of the people involved in these activities are volunteers and largely unpaid.

On Dec 19, 2018, at 13:24, Gregory P. Smith <greg at krypto.org> wrote:

Ned - and any release manager in this situation in the future - has a default valid answer to this request: No.

If we're ever going to do an "EL" or "LTS" Python, that should be decided and agreed upon *long before the end of its existing planned maintenance cycle* instead of right as it is ending. Ideally before the first x.y.0 with agreement of the release manager. Though it'd likely be fine to have that conversation about 3.7 as it is still young, the RM gets final say into if or how that would work. I know that I won't be bothering with 3.6 backport/review work myself anymore outside of special circumstances.

I think Greg says it better than I could - thanks!

We have had several years to discuss this. There have been a number of proposals but none have resulted in a reviewed, approved PEP. Literally one day before the final bugfix release is not the time to make such a big change in our plans. It certainly is legitimate and necessary to consider such changes in the future when we have our new governance process in place and, at that time, we can consider revising our plans for 3.7 which is still relatively early in its bugfix phase. And, if there were concrete proposals with funding sources for co-ordinating extended support for 3.6, we should consider them. I think a reasonable target is to have a final discussion and decision made by the next Language Summit upcoming in May; there is plenty of work to be done before then, i.e. start new or revise exiting PEPs.

But in the absence of any of that at the moment, it would be a disservice to all to consider making such major changes and commitments now. And it's not something that I as release manager or any of us individually as core developers can or should do.

--Ned

P.S. Thanks for bringing this up, Serihy, and thanks for everyone's thoughtful responses.

-- Ned Deily nad at python.org -- []

More information about the python-committers mailing list