Unsupporting python3.5
On Thu, Oct 10, 2019 at 9:31 AM Matti Picus matti.picus@gmail.com wrote:
According to NEP 29, numpy 1.18 will be released after Sept 2019, which as I understand it is the cutoff for Python 3.5. In PR 14673 I proposed removing it from the test matrix and also removing some shims in the code to support it - meaning that in order to use Numpy 1.18+ you will need to use Python 3.5+. Is this the intention of the NEP or is the intention only that we no longer test it and no longer supply wheels? If the latter, at what point do we remove support code for unsupported versions?
Note the cost of this code is negligible, it is more a question of what is the correct/desired approach.
I think we can support 3.5 as long as we please, the question is how long we *want* to support it. I don't plan to release 1.18 wheels for 3.5, but I'm concerned about making 1.18 outright incompatible with 3.5. I would like to see the random interface settle before we do that. So my preference would be to drop 3.5 in 1.19 with a future warning in the 1.18 release notes. Alternatively, we could backport all the random changes to 1.17, but I would rather not do that.
Chuck
On Thu, Oct 10, 2019, at 09:34, Charles R Harris wrote:
I think we can support 3.5 as long as we please, the question is how long we *want* to support it. I don't plan to release 1.18 wheels for 3.5, but I'm concerned about making 1.18 outright incompatible with 3.5. I would like to see the random interface settle before we do that. So my preference would be to drop 3.5 in 1.19 with a future warning in the 1.18 release notes. Alternatively, we could backport all the random changes to 1.17, but I would rather not do that.
The language in the NEP is:
"we recommend that they support at least all minor versions of Python introduced and released in the prior 42 months"
i.e., a lower bound for support, such that compatibility with more versions of Python is perfectly OK and, in the case of NumPy, probably encouraged. The NEP is meant to lift the burden of very long support cycles from smaller projects.
Stéfan
On Thu, Oct 10, 2019 at 6:02 PM Stefan van der Walt stefanv@berkeley.edu wrote:
On Thu, Oct 10, 2019, at 09:34, Charles R Harris wrote:
I think we can support 3.5 as long as we please, the question is how long we *want* to support it. I don't plan to release 1.18 wheels for 3.5, but I'm concerned about making 1.18 outright incompatible with 3.5. I would like to see the random interface settle before we do that. So my preference would be to drop 3.5 in 1.19 with a future warning in the 1.18 release notes. Alternatively, we could backport all the random changes to 1.17, but I would rather not do that.
The language in the NEP is:
"we recommend that they support at least all minor versions of Python introduced and released in the prior 42 months"
i.e., a lower bound for support, such that compatibility with more versions of Python is perfectly OK and, in the case of NumPy, probably encouraged. The NEP is meant to lift the burden of very long support cycles from smaller projects.
Stéfan
The 1.18.0rc1 is about one month out, so we should spend some effort on those PRs and issues with the 1.18 milestone. Dealing with issues and milestones, plus putting together the release notes, is the major pain point in making releases these days.
Chuck
On Fri, Oct 11, 2019 at 4:18 AM Charles R Harris charlesr.harris@gmail.com wrote:
On Thu, Oct 10, 2019 at 6:02 PM Stefan van der Walt stefanv@berkeley.edu wrote:
On Thu, Oct 10, 2019, at 09:34, Charles R Harris wrote:
I think we can support 3.5 as long as we please, the question is how long we *want* to support it. I don't plan to release 1.18 wheels for 3.5, but I'm concerned about making 1.18 outright incompatible with 3.5. I would like to see the random interface settle before we do that. So my preference would be to drop 3.5 in 1.19 with a future warning in the 1.18 release notes. Alternatively, we could backport all the random changes to 1.17, but I would rather not do that.
I'm not sure I like this approach, which is reflected in the current version of https://github.com/numpy/numpy/pull/14673. If we stop testing 3.5 in CI, don't release 3.5 wheels and remove the PyPI trove classifier for it (so installation tools may not install it anymore), then what's the point of saying we "don't drop it"? I'd rather keep it fully supported for one more month and release a couple of wheels, or just drop it completely. I don't have much of a preference which option is better, just would like to avoid half-dropping it.
Cheers, Ralf
The language in the NEP is:
"we recommend that they support at least all minor versions of Python introduced and released in the prior 42 months"
i.e., a lower bound for support, such that compatibility with more versions of Python is perfectly OK and, in the case of NumPy, probably encouraged. The NEP is meant to lift the burden of very long support cycles from smaller projects.
Stéfan
The 1.18.0rc1 is about one month out, so we should spend some effort on those PRs and issues with the 1.18 milestone. Dealing with issues and milestones, plus putting together the release notes, is the major pain point in making releases these days.
Chuck _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
On Fri, Oct 18, 2019 at 3:06 AM Ralf Gommers ralf.gommers@gmail.com wrote:
On Fri, Oct 11, 2019 at 4:18 AM Charles R Harris < charlesr.harris@gmail.com> wrote:
On Thu, Oct 10, 2019 at 6:02 PM Stefan van der Walt stefanv@berkeley.edu wrote:
On Thu, Oct 10, 2019, at 09:34, Charles R Harris wrote:
I think we can support 3.5 as long as we please, the question is how long we *want* to support it. I don't plan to release 1.18 wheels for 3.5, but I'm concerned about making 1.18 outright incompatible with 3.5. I would like to see the random interface settle before we do that. So my preference would be to drop 3.5 in 1.19 with a future warning in the 1.18 release notes. Alternatively, we could backport all the random changes to 1.17, but I would rather not do that.
I'm not sure I like this approach, which is reflected in the current version of https://github.com/numpy/numpy/pull/14673. If we stop testing 3.5 in CI, don't release 3.5 wheels and remove the PyPI trove classifier for it (so installation tools may not install it anymore), then what's the point of saying we "don't drop it"? I'd rather keep it fully supported for one more month and release a couple of wheels, or just drop it completely. I don't have much of a preference which option is better, just would like to avoid half-dropping it.
That's fair. The 1.17.3 release supporting Python 3.5--3.8 went well enough. The only glitch was that I had to explicitly use OSX 10.6 and icode 6.4 for the 3.5 wheels on the Mac.
Chuck
On Fri, Oct 18, 2019 at 2:36 PM Charles R Harris charlesr.harris@gmail.com wrote:
On Fri, Oct 18, 2019 at 3:06 AM Ralf Gommers ralf.gommers@gmail.com wrote:
On Fri, Oct 11, 2019 at 4:18 AM Charles R Harris < charlesr.harris@gmail.com> wrote:
On Thu, Oct 10, 2019 at 6:02 PM Stefan van der Walt < stefanv@berkeley.edu> wrote:
On Thu, Oct 10, 2019, at 09:34, Charles R Harris wrote:
I think we can support 3.5 as long as we please, the question is how long we *want* to support it. I don't plan to release 1.18 wheels for 3.5, but I'm concerned about making 1.18 outright incompatible with 3.5. I would like to see the random interface settle before we do that. So my preference would be to drop 3.5 in 1.19 with a future warning in the 1.18 release notes. Alternatively, we could backport all the random changes to 1.17, but I would rather not do that.
I'm not sure I like this approach, which is reflected in the current version of https://github.com/numpy/numpy/pull/14673. If we stop testing 3.5 in CI, don't release 3.5 wheels and remove the PyPI trove classifier for it (so installation tools may not install it anymore), then what's the point of saying we "don't drop it"? I'd rather keep it fully supported for one more month and release a couple of wheels, or just drop it completely. I don't have much of a preference which option is better, just would like to avoid half-dropping it.
That's fair. The 1.17.3 release supporting Python 3.5--3.8 went well enough. The only glitch was that I had to explicitly use OSX 10.6 and icode 6.4 for the 3.5 wheels on the Mac.
So do you have a preference for dropping or not dropping for 1.18?
Ralf
On Sat, Oct 19, 2019 at 4:42 AM Ralf Gommers ralf.gommers@gmail.com wrote:
On Fri, Oct 18, 2019 at 2:36 PM Charles R Harris < charlesr.harris@gmail.com> wrote:
On Fri, Oct 18, 2019 at 3:06 AM Ralf Gommers ralf.gommers@gmail.com wrote:
On Fri, Oct 11, 2019 at 4:18 AM Charles R Harris < charlesr.harris@gmail.com> wrote:
On Thu, Oct 10, 2019 at 6:02 PM Stefan van der Walt < stefanv@berkeley.edu> wrote:
On Thu, Oct 10, 2019, at 09:34, Charles R Harris wrote:
I think we can support 3.5 as long as we please, the question is how long we *want* to support it. I don't plan to release 1.18 wheels for 3.5, but I'm concerned about making 1.18 outright incompatible with 3.5. I would like to see the random interface settle before we do that. So my preference would be to drop 3.5 in 1.19 with a future warning in the 1.18 release notes. Alternatively, we could backport all the random changes to 1.17, but I would rather not do that.
I'm not sure I like this approach, which is reflected in the current version of https://github.com/numpy/numpy/pull/14673. If we stop testing 3.5 in CI, don't release 3.5 wheels and remove the PyPI trove classifier for it (so installation tools may not install it anymore), then what's the point of saying we "don't drop it"? I'd rather keep it fully supported for one more month and release a couple of wheels, or just drop it completely. I don't have much of a preference which option is better, just would like to avoid half-dropping it.
That's fair. The 1.17.3 release supporting Python 3.5--3.8 went well enough. The only glitch was that I had to explicitly use OSX 10.6 and icode 6.4 for the 3.5 wheels on the Mac.
So do you have a preference for dropping or not dropping for 1.18?
Let's not drop it. Four weeks isn't that long to wait.
Chuck
That's fair. The 1.17.3 release supporting Python 3.5--3.8 went well enough. The only glitch was that I had to explicitly use OSX 10.6 and icode 6.4 for the 3.5 wheels on the Mac.
So do you have a preference for dropping or not dropping for 1.18?
Let's not drop it. Four weeks isn't that long to wait.
+1 from the peanut gallery.
Cheers,
Evgeni
participants (5)
-
Charles R Harris -
Evgeni Burovski -
Matti Picus -
Ralf Gommers -
Stefan van der Walt