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 :)

The deprecation cycle is of two
versions, so I think it should be enough to support the last two numpy
versions at the time of the previous scipy release. So, scipy 0.19
would support from numpy 1.10, that was released in October last year,
and people would have had a year to adapt.

Note also that pip's
default behaviour is to upgrade every dependency.

That pip behavior is completely braindead, and there is agreement by the pip/packaging crowd that it needs to be changed to a more minimalist upgrade strategy. The debate is just about how to introduce the change.

Side question: do we check the other way around? Will a new numpy work
with an old scipy? Say, numpy 1.11 with scipy 0.13 (as old as 1.8)?

Yes it should, except for the few things that needed to be adapted in newer scipy versions for removals of deprecated features and unintentional backwards compat breaks. Older scipy binaries will also work with a newer numpy.

Ralf