Im getting py3.5/np1.10 test failures due to numerics on #12419 that could use a decision on this.... Added to the weekly call agenda...

With matplotlib 3.1 likely out in 2019, I’m good with dropping Python 3.5.

I guess that depends on when we plan to release v3.1. Also, I am trying to figure out if it is more sensible to read that policy as a open interval or a closed interval (in other words, because it was more than a year between py3.5 and py3.6, and the 3 year boundary in between them, should the policy be read as including py3.5 or not)?

support minor versions of Python initially released in the previous 3 years

So if no version of python is released within 3 years, we can drop support for every version.

Since that can't be how this is meant, one would rather look at when the version after that was released and add 3 years. So python 3.6 was released end of 2016, meaning python 3.5 can be dropped end of 2019. Or, one can interpret it such as python 3.5.5 being released in February this year, such that support needs to stay up till february 2021.

Or, much preferred, the steering council should first rephrase that nonsensical sentence and after that it is clear how long which versions are to be supported.

Or, one can interpret it such as python 3.5.5 being released in February this year

I don't think this is the case. 3.5.5 is the micro version released in Feb 2018. The minor version, 3.5, was unambiguously released in 2016 2015

^ Did you mean 2015?

I think we should stay with our 6 month release cycle, which means if we aim for February 2019 we will actually hit March 2019 ;)

So if no version of python is released within 3 years, we can drop support for every version.

If there are no minor versions of python for 3 years (given that they are on a 18 month release cycle) I think we can call the whole community dead and close up shop (or at least re-address the policy).

What I intended that sentence to mean was "support minor version of python that had their X.Y.0 release within a 3*365 day window preceding our intended release date". The intent was to have us mostly supporting 2 versions of python (and sometimes 3 versions around upstream releases). Sorry for not being clear / confusion about calendar years.

Upstream seems to be targeting 5 years of support for python minor versions. Given that we targeting a 6 month minor release cycle, we support a bug-fix branch for only the most recent minor (leaving aside the 2.2.x LTS as a spcial case) this means we effectively support any given minor version for 3.5 years out of it's 5 year life.

In terms of usage numbers we have pypi stats:

https://pypistats.org/packages/matplotlib

(what happened to python 3 adoption in the last few weeks!!)

and some numbers from @pzwang at Anaconda

https://qa.debian.org/popcon.php?package=matplotlib is also interesting, but only gives us 2 vs 3 and no minor version (or matplotlib version) breakdown)

I expect to see a big swing from 3.6 -> 3.7 as it starts to get packaged and pushed out (ex anaconda 5.3 is py37, I think F29 will be py37, ubuntu 18.10 will be py37, debian is working on the transition, and arch is already done).

That wording went in with too-little discussion, I was expecting this for this cycle ;)

@tacaswell - so MPL 3.1 is >= py3.6 and >= np1.10? We could probaby change the tests if thats correct...

As currently written that is the case 😈 .

I view this issue as the discussion on if we are going to stick to the written policy or adjust the policy to keep 3.5 for a while longer.

Let's not, unless there are compelling arguments not to, which I haven't seen so far.
It was already seriously considered whether to support py3.5 in mpl3.0, it's more than time to drop it.

I vote to drop py3.5 and np1.10

(For #12419 itself I think just bumping to numpy 1.11 is enough, see comment in that thread.
But there are other advantages to Py3.6 as listed in the original post.)

(For sure - my vote wasn't just based on #12419, the testing issues of which can easily be worked around).

(though I'll change my vote if there are omnibus PRs that change every .format in the code to f-strings. 😈 )

Fortunately that can be automated... (https://github.com/asottile/pyupgrade#f-strings)

To have some basic project management applied, it would make sense to have a list of issues that would benefit from dropping a dependency. Those should be real problems to be solved, since there is no need for f"string" support and getting a lot of "Since we dropped py3.5 we might as well..."-PRs in would effectively bind more energy than it would free. Only if there is a cost/benefit ratio > 1, it makes sense to pursue such step, completely independent on what the minimal version policy says.

Two of my PRs suffer from np1.10 issues: #11859, #12419. Both can be worked around, but it'd be nice to not have to if 1.10 isn't being used much...

Real problems: By dropping the Python version dependencies, we reduce the number of test entries on travis and AppVeyor, decreasing test times. Also, we reduce the number of wheels we need to compile and upload to PyPI.

I also think that keeping the code as simple as allowed by recent Pythons actually qualifies as fixing a real problem (namely the mess that many parts of mpl's implementation is)...

Closing. Python 3.5 is no longer supported on matplotlib 3.1. #12538