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