[SciPy-Dev] Policy for minimum numpy version

[Ralf Gommers]

On Thu, Aug 11, 2016 at 5:05 AM, Eric Quintero <ericq at 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 at gmail.com> wrote:
> >
> > On 3 August 2016 at 12:48, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> >> On Wed, Aug 3, 2016 at 10:32 AM, Daπid <davidmenhur at gmail.com> wrote:
> >>>
> >>> On 3 August 2016 at 09:48, Ralf Gommers <ralf.gommers at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160811/6175043d/attachment.html>