[SciPy-Dev] Policy for minimum numpy version

[Eric Quintero]

So far, it seems no-one has argued against bumping the minimum version to 1.8. If this is the necessary level of consensus, what steps need to happen to make this transition?

-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.
> 
>> 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).
> 
> 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? If the component is mission critical
> and upgrading is a risk, I'd expect the same would be true for scipy.
> 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.
> 
> /David.
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/scipy-dev