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@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.
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@scipy.org https://mail.scipy.org/mailman/listinfo/scipy-dev