In light of #7423, I wonder if we should also clarify our support policy for Python 3 releases. Typically the answer has been "when traffic to PyPI falls before a certain level", but it would be nice to have something to point at with regards when (e.g., currently) 3.5 support will be dropped.
From https://github.com/pypa/pip/issues/8169#issuecomment-621178017:
We'll likely be dropping Python 3.5 the same time as Python 2.7 btw -- since Python 3.5 goes EoL in August / October 2020.
I've love to know the canonical criteria for it though.
I don't think we really have criteria. And I'm mildly against making strict rules, as they would most likely result in us dropping support sooner than we would otherwise do. But I get that a formal rule helps people plan. So I don't have a problem with with having one.
Python 2 was a special case, because supporting Python 2 makes it significantly harder to maintain pip. Conversely, there's not that much in any given Python 3 release that has a support impact. Dropping 3.5 allows us to use f-strings, which will be nice. Dropping 3.6 will let us use data classes. Dropping 3.7 gives us the walrus operator, positional-only parameters and built in importlib.metadata
. All nice, but not really major like dropping Python 2 will be.
Edit: For 3.x I should say that I'm against deciding based on PyPI traffic. That was a 2.x-specific measure. I assume any 3.x desupport policy would be based around when core Python support ends for that release.
so would pip drop support around the time a python version is eol or would there be one last pip release supporting it after eol before dropping?
As I said, there's no current policy so that's up for debate.
so would pip drop support around the time a python version is eol or would there be one last pip release supporting it after eol before dropping?
As Paul said, there is currently no officially defined policy but the "one last pip release after eol" policy currently has my preference.
My understanding has been, in general, we'll drop support for a Python version when PyPI metrics indicate usage below 5% or it goes EOL -- whichever happens first. That was a rough metric for "relevant" Python version... and Python 2.7 was a special snowflake obviously.
@pfmoore My understanding is that we've been using PyPI data for quite a while now, when determining whether we drop support (I know we did this for 2.6, 3.3, 3.4) and I don't think that was a Python 2.7-specific approach.
My preference on EoLs, is to not have a "one last pip release after EoL".
Okay, we've come super close to 20.3 release.
Looks like Python 3.5 usage on PyPI is hovering around 6.6% which is higher than the 5% that we've used for when determining when to drop support for 2.6 / 3.3 / 3.4. The trend on Python 3.5's usage numbers seems to be well on-track to be <5% by Jan 2021. I propose that we drop support for Python 3.5 in pip 21.0 (i.e. pip 20.3 is the last Python 3.5 compatible pip release).
I'm OK on having this (drop support on <5% PyPI usage) our official policy -- if we all agree that it'd be OK to document status quo as a policy -- with a "maintainers' discretion" escape hatch, in case extra-ordinary circumstances arise.
Please see PR https://github.com/pypa/pip/pull/8778 to deprecate support for Python 3.5.
And please see PR https://github.com/pypa/pip/pull/8927 to add https://github.com/pypa/pip/issues/8181#issuecomment-647214563 to the docs.
Thanks @hugovk! ^>^
Most helpful comment
Okay, we've come super close to 20.3 release.
Looks like Python 3.5 usage on PyPI is hovering around 6.6% which is higher than the 5% that we've used for when determining when to drop support for 2.6 / 3.3 / 3.4. The trend on Python 3.5's usage numbers seems to be well on-track to be <5% by Jan 2021. I propose that we drop support for Python 3.5 in pip 21.0 (i.e. pip 20.3 is the last Python 3.5 compatible pip release).
I'm OK on having this (drop support on <5% PyPI usage) our official policy -- if we all agree that it'd be OK to document status quo as a policy -- with a "maintainers' discretion" escape hatch, in case extra-ordinary circumstances arise.