I am 👍 , but it would be very easy to talk me out of it.

I am 👍*100, mostly 'cause it's my code that's a mess 'cause of this.

I am assuming that this would be for v2.1? I am -1 for doing so for v2.0,
but can be convinced to do so for v2.1.

On Thu, Nov 3, 2016 at 9:29 AM, hannah notifications@github.com wrote:

I am 👍*100, mostly 'cause it's my code that's a mess 'cause of this.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#7396 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AARy-PPbZP3Uzxjg1YhdmW65KkpmEELWks5q6eGsgaJpZM4KoIwo
.

That seems like a good idea.

(For scikit-learn the criteria is to support at least what is in the latest Ubuntu LTS, which is currently 1.8).

Another (rather minor) plus is that we can finally enable those #defines that stop NumPy headers from warning about stuff that changed in the 1.7.0 C bindings. I might have a patch for that already, somewhere...

Oh, actually turns out that macro is already enabled and since there are no errors, we don't use any of the deprecated API. One less explicit benefit I guess.

I'm happy with seeing this change for 2.1.

What is the big argument for not bumping it to 1.7 now? Is this conservatism doing us and our users any big favor? Isn't an new major version number a good place to make such a change?

Scipy 0.18.0: "This release requires Python 2.7 or 3.4-3.5 and NumPy 1.7.1 or greater." I don't see any reason why we should lag scipy in this respect.

The argument against, and I'm not sure where I stand on it personally, is that bumping the numpy version gives users stuck on the old version no upgrade path for the new styles; therefore when they move, they have an even bigger change to deal with.

And I think the counter-argument is that anyone who can install an up-to-date matplotlib can just as easily install an up-to-date numpy.

Are there really any users out there for which this is not true?

Bumping numpy leads to needing to rebuild packages which are linked to numpy's C-API. Matplotlib is usually a leaf in the graph (numpy's not), so bumping matplotlib doesn't require rebuilding other stuff.

Two more data points: Ubuntu 14.04LTS has numpy 1.8.1. RHEL 7 has numpy 1.7.1.

My argument stands: yes, it is possible that someone, somewhere, will be bent out of shape by not being able to install 2.x natively (that is, without Anaconda or similar) without additional updates, and will be left stuck with our old style. They will have to keep using 1.5.3, or whatever earlier version they are already using--and have probably been using happily for a long time, style and all. (On the plus side, they will not be tripping over whatever undetected bugs and glitches we have introduced with the style overhaul--and I am sure there will be some.) But I think that such cases of user pain will be so rare, if they occur at all, that they should not block us.

My argument against bumping it for 2.0 is that the promise has been that
2.0 would be (mostly) just style changes. There is no pressing need to bump
it for 2.0, and numpy 1.6 was the minimum requirement for our v1.5. So
someone being told that the upgrade to 2.0 is "just style changes" would be
quite confused when he has to recompile everything because numpy got
upgraded unexpectedly.

On Thu, Nov 17, 2016 at 5:24 PM, Eric Firing notifications@github.com
wrote:

My argument stands: yes, it is possible that someone, somewhere, will be
bent out of shape by not being able to install 2.x natively (that is,
without Anaconda or similar) without additional updates, and will be left
stuck with our old style. They will have to keep using 1.5.3, or whatever
earlier version they are already using--and have probably been using
happily for a long time, style and all. (On the plus side, they will not be
tripping over whatever undetected bugs and glitches we have introduced with
the style overhaul--and I am sure there will be some.) But I think that
such cases of user pain will be so rare, if they occur at all, that they
should not block us.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#7396 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AARy-OPlSjEKSXej-EyOfxo-SXlWvLLKks5q_NQZgaJpZM4KoIwo
.

On 2016/11/17 12:35 PM, Benjamin Root wrote:

My argument against bumping it for 2.0 is that the promise has been that
2.0 would be (mostly) just style changes. There is no pressing need to bump
it for 2.0, and numpy 1.6 was the minimum requirement for our v1.5. So
someone being told that the upgrade to 2.0 is "just style changes" would be
quite confused when he has to recompile everything because numpy got
upgraded unexpectedly.

Weak argument. Note the "mostly", and the fact that until 2.0 is
released we have plenty of wiggle-room. Do you really think the sort of
person who is installing a hot-off-the-press matplotlib, natively,
without something like Anaconda, is going to be "quite confused" if we
advertise the release as requiring 1.7.1, when we had said it would be
mostly just style changes? And this person has to be among the small
population of people still using numpy 1.6.

Right now, for #7476, we need 1.7.1; or we need to make our own version
of isclose, which we would then remove in master. #7476, or something
like it, is actually well beyond a style change, but is critical to
making the style change work.

2.0 is the right place to make the change. It will make it easier to
progress towards 2.1, backporting bug-fixes to 2.x.

I am fine with bumping the requirement for numpy to 1.7 for 2.0.

To be clear @efiring, that's the first time a concrete benefit of moving has actually been mentioned--you may want to consider leading with that next time. Last word before that was "nevermind, I don't really need it" from @anntzer.

@dopplershift, agreed, I failed to say why I suddenly thought it mattered.

But there is a more general argument for this sort of change. The larger the range of numpy versions we support, the larger the potential for running into problems with numpy bugs and behavior changes. And the greater the delay between the time a new feature is introduced and the time when we can take advantage of it. In other words, there is a real benefit to matplotlib development in moving up the minimum version, and a real cost in delaying the move.

Agree completely--so long as we do it with an eye to the real benefits we'll see (i.e. new features) and acknowledge the cost to our users (such as those who have to have a sysadmin build their own stack on, e.g. solaris)

I would come down on the side of bumping the minimum version over vendoring a version of isclose in 2.0 but then not on master.

I'm 👍 as well now.

Ok, now that there is a concrete reason for bumping the minimum version
after we promised we wouldn't for 2.0, I will agree to that.

As for the general argument about what versions of numpy to support, I have
no problem with bumping up the minimum version -- but you must show me
evidence of a benefit and that benefit should outweigh the costs. Right
now, I am stuck on numpy 1.9 at work because version 1.10 and 1.11 have
each had separate show-stopper bugs for my projects. I am right now
evaluating the 1.12 beta, but it seems that it might also have another
show-stopper bug (trying to trace down the fault right now). The point is
that on production systems that have had its results verified, we may have
very esoteric reasons for not upgrading certain parts of the stack for
awhile.

(Yes, I know, using a CI would mitigate this significantly...)

On Thu, Nov 17, 2016 at 10:29 PM, Ryan May notifications@github.com wrote:

I'm 👍 as well now.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#7396 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AARy-FlOqRffBEg57CjZp05cANKhueHlks5q_RuIgaJpZM4KoIwo
.

Closed by #7483