On Thu, Aug 11, 2016 at 5:05 AM, Eric Quintero <ericq@caltech.edu> wrote:
So far, it seems no-one has argued against bumping the minimum version to 1.8. If this is the necessary level of consensus,
I think it is.
what steps need to happen to make this transition?
A PR with changes to setup.py, scipy/__init__.py, pavement.py and doc/release/0.19.0-notes.rst for changing 1.7.1/1.7.2 to 1.8.2 at least. And then in the same or another PR all the special-casing and tests skipped for 1.7.x can be removed.
-Eric Q.
On Aug 5, 2016, at 7:06 AM, Daπid <davidmenhur@gmail.com> wrote:
On 3 August 2016 at 12:48, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Wed, Aug 3, 2016 at 10:32 AM, Daπid <davidmenhur@gmail.com> wrote:
On 3 August 2016 at 09:48, Ralf Gommers <ralf.gommers@gmail.com>
wrote:
There's no conclusion here yet, but the other responses to this email were examples of pain points with 1.8 and that the cost of upgrading numpy has gone down.
In general I think we bump the minimum version if the costs are
starting
to outweigh the benefits. That's probably the case for 1.7 now. Looking back, we typically have supported 4 numpy versions with a scipy release. Right now we're at 5 (1.7 - 1.11), and numpy 1.12 will likely be out before the next scipy release.
What is the use case that requires an 2 years and 9 months old numpy and the latest, bleeding edge, scipy?
See the responses to the last time you asked this, those are still valid: https://mail.scipy.org/pipermail/scipy-dev/2014-December/020266.html :)
I totally forgot I ever said that, sorry. Thank you for bearing with my fish memory.
No worries.
A lot more packages depend on numpy than on scipy, so upgrading numpy
can have way more impact.
I see. I guess this is mostly relevant as a part of a large package repository, where there is a higher chance of finding outdated packages. On the other hand, numpy is pretty backwards compatible, except for long deprecation cycles, so there is usually plenty of time to upgrade (one year of deprecation, plus one year of scipy catching up in my scheme).
One year is not a lot at all for deployed server installs, companies shipping qualified sets of packages, etc. And even occasional users won't be updating actively. For people reading this mailing list a year is a lot, but those are not average users.
All the backwards incompatible changes I can think of so far required fairly minor adjustments (for example, random_integers -> randint), unless I have forgotten something (fish memory). Or, of course, the codebase is huge, but I have no experience there.
And there may be institutes/companies that ship a fixed version of
numpy that needs to be supported for a long time.
My question in this case remains, if they ship an ancient numpy, why would they need the latest scipy?
They may need a specific feature or bugfix.
If the component is mission critical
and upgrading is a risk, I'd expect the same would be true for scipy.
Sure, but any extra package to upgrade is extra work. And work is time/money. This really comes down to putting the pain somewhere, either with some devs that run into an issue with older numpy when making a PR, or with a very hard to estimate (but certainly much larger) group of users.
Most other cases would be covered by using virtualenvs or anaconda.
And I would add one reason to encourage people to keep up to date: deprecation cycles work under the assumption that developers try every version, and use the warnings to adapt their code. If someone were to upgrade directly from numpy 1.8 to 1.12, the safety net is circumvented, and they may find unexpected changes in behaviour.
Most (ideally all) of those should be exceptions or things like shape changes, not silent changes in numerical values. Anyway, again this a cost/benefit trade-off. Ralf