I'm in favour of this change, but I think we should discuss this, and indeed our backwards compatibility stance, at SciPy 2013. Perhaps we should arrange a "developers" meeting (including anybody who cares/has committed, not just those with commit rights) at SciPy...

The rule of thumb has generally been to look at what the long-term-support releases of RedHat, Debian and Ubuntu were currently at, and then at things like EPD and Anaconda, to find the minimum required version... I haven't done that research lately...

The rule of thumb has generally been to look at what the long-term-support releases of RedHat, Debian and Ubuntu were currently at, and then at things like EPD and Anaconda, to find the minimum required version...

Sounds like a useful resource which other projects outside of matplotlib would find valuable (@rhattersley 😉). Do you know if IPython/Scipy + friends follow a similar pattern?

RHEL6 is using Numpy 1.4.1 (maybe higher since this advisory is old):
http://rhn.redhat.com/errata/RHBA-2012-0986.html
Looks like as of RHEL6.4, there is scipy 0.7.2:
http://rhn.redhat.com/errata/RHEA-2013-0341.html

punting this as we have not touched it in 9 months and it clearly is not going to get done in the next two weeks.

Some of the API changes have replacements available in older numpy releases, but some macros such as NPY_IN_ARRAY were changed in 1.7 (into NPY_ARRAY_IN_ARRAY) and deprecated immediately. I guess we're going to need our own compatibility layer if we want to both support numpy versions prior to 1.7 and not get deprecation warnings.

Ubuntu 10.04 LTS (lucid) is still supported for about half a year, and it has python-numpy 1:1.3.0-3build1.

Ubuntu 12.04 LTS (precise) has python-numpy 1:1.6.1-6ubuntu1.

Ubuntu 14.04 LTS (trusty) has python-numpy 1:1.8.1-1ubuntu1.

Debian 6.0 (squeeze) is getting security updates until February 2016, and has python-numpy 1.4.1-5.

Debian 7.0 (wheezy) is the current stable distribution, and has python-numpy 1:1.6.2-1.2.

RHEL 4 is on "Extended Life Cycle Support" until March 2017, and... I don't know how to find their official package versions. The search at rpm.pbone.net finds numpy 1.1.1 for RHEL 4, numpy 1.2.1 for RHEL 5, numpy 1.4.1 for CentOS 6, and numpy 1.7.1 for CentOS 7.

The Anaconda repository seems to have numpy packages from 1.5 to 1.9. I couldn't figure out if they have any kind of long-term support promises. Presumably they expect their users to upgrade the packages often.

In the Python(x,y) changelog they mention numpy 1.6.0.1 in "Version 2.6.6.1 (04/28/2011)". My impression is that they encourage users to update the packages often.

The documentation at http://matplotlib.org/users/installing.html already mentions a requirement of numpy 1.6 or later, and if we keep to that it would be easy (with respect to numpy versions) to install matplotlib on Ubuntu 12.04, Debian 7.0, and CentOS 7.

That seems pretty compelling to stick with 1.6 as the minimum.

On the other hand, if you are using one of the LTS in such a way that you must rely on the system-installed numpy, how likely are you to be installing new versions of matplotlib?

Quite possible, actually. Since numpy serves as a compiled library for
other packages to link in, you really don't want to have some packages
compiled against a system numpy and others compiled against a local numpy.

On Mon, Sep 22, 2014 at 11:38 AM, Thomas A Caswell <notifications@github.com

wrote:

That seems pretty compelling to stick with 1.6 as the minimum.

On the other hand, if you are using one of the LTS in such a way that you
must rely on the system-installed numpy, how likely are you to be
installing new versions of matplotlib?

—
Reply to this email directly or view it on GitHub
#2092 (comment)
.

how likely are you to be installing new versions of matplotlib?

I sympathise with this view too. I agree with what @WeatherGod is saying, but in truth, the impact of maintaining so many ancient versions of dependencies is simply not worth the developer hours (unless, potentially, some such organisation were directly contributing sufficient developer hours).

The changes needed to ensure compatibility with 1.6 are minimal. The majority of #3547 is about supporting future versions by removing compatibility warnings, just 447c90d fixes something with 1.6 and 0c074fc ensures that we get a Travis test with 1.6. For the time being I'd say we can easily support 1.6.