Repository navigation
Dropping support for Py3.5 and numpy 1.10 #12358
Description
Our dependencies policy (https://matplotlib.org/devel/min_dep_policy.html) states that we'll only
- support minor versions of Python initially released in the previous 3 years
- support minor versions of numpy initially released in the previous 3 years or oldest that supports the minimum python version (which ever is higher)
We will bump the minimum python and numpy versions as we can every minor and major release, but never on a patch release.
Python 3.5 was released on Sept. 13, 2015 (https://www.python.org/dev/peps/pep-0478/) and numpy 1.10 was released on Oct. 6th, 2015; we should thus be able to drop support for them in Matplotlib 3.1. Python 3.6 brings in quite a few nice features (f-strings, __fspath__, ordered kwargs); the last one, in particular, is relevant for our "batch setters" (artist.set(foo=bar, baz=quux), rather than "just" being a source-code nicety). A quick look at numpy 1.11's changelog doesn't suggest anything particularly relevant, but if anyone needs it they should feel free to bump the dependency.
For those keeping score at home, the following relevant release dates are
Python 3.6: Dec. 23, 2016
Python 3.7: Jun. 27, 2018
numpy 1.11: Mar. 27, 2016
numpy 1.12: Jan. 15, 2017 (np.full respects the filler's dtype -> #10571/#12379)
numpy 1.13: Jun. 07, 2017
numpy 1.14: Jan. 06, 2018 (np.genfromtxt defaults to latin-1 -> #13621)
numpy 1.15: Jul. 23, 2018 (adds np.histogram_bin_egdes -> #8638)
Activity
jklymak commentedon Oct 9, 2018
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...
dopplershift commentedon Oct 9, 2018
With matplotlib 3.1 likely out in 2019, I’m good with dropping Python 3.5.
WeatherGod commentedon Oct 9, 2018
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)?
ImportanceOfBeingErnest commentedon Oct 9, 2018
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.
phobson commentedon Oct 9, 2018
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
20162015jklymak commentedon Oct 9, 2018
^ Did you mean 2015?
tacaswell commentedon Oct 9, 2018
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 ;)
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 ;)
jklymak commentedon Oct 9, 2018
@tacaswell - so MPL 3.1 is >= py3.6 and >= np1.10? We could probaby change the tests if thats correct...
tacaswell commentedon Oct 9, 2018
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.
anntzer commentedon Oct 9, 2018
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.
jklymak commentedon Oct 9, 2018
I vote to drop py3.5 and np1.10
anntzer commentedon Oct 9, 2018
(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.)
jklymak commentedon Oct 9, 2018
(For sure - my vote wasn't just based on #12419, the testing issues of which can easily be worked around).
jklymak commentedon Oct 9, 2018
(though I'll change my vote if there are omnibus PRs that change every
.formatin the code to f-strings. 😈 )anntzer commentedon Oct 9, 2018
Fortunately that can be automated... (https://github.com/asottile/pyupgrade#f-strings)
ImportanceOfBeingErnest commentedon Oct 9, 2018
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.
jklymak commentedon Oct 9, 2018
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...
dopplershift commentedon Oct 9, 2018
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.
anntzer commentedon Oct 9, 2018
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)...
timhoffm commentedon Dec 17, 2018
Closing. Python 3.5 is no longer supported on matplotlib 3.1. #12538