Hi all, Starting with the summary of my email of earlier today: I'd like to pick a time for when we release SciPy 1.0, and what is still essential to do for that version number. We've discussed this a couple of times before [1,2]. We're now at the point where most of the major gaps have been filled though, so it looks to me like it's time to just pick a date for it (either after or instead of 0.19.0) and then fix up the last things that we think we really need for a 1.0 release. Here are the things that I see as essential: - Getting project organization in order: governance and CoC at least (see my other email of today). - scipy.signal: clean up the messes in wavelets and B-splines. - scipy.signal: unified filter API [3] - scipy.spatial: remove Python implementation of KDTree, just keep cKDTree - scipy.interpolate: not sure of the details, but I think there are some new interpolator classes and a spline PR that aren't quite finished? - Remove some deprecated items (weave is the biggest one), and decide now if there's anything else we need to deprecate. - Merge or close more PRs. We've stabilized them at around 120-130 open ones, but that's not really good enough if there are (almost) finished PRs that no one has looked at in a year. This may be the single biggest task. We shouldn't make the above list too long, otherwise we won't get there. Really, SciPy is production quality software (with a few dusty corners), so we should limit ourselves to listing what is essential here. Timing: I suspect that we want to deprecate some more things, and that 4 months is a little too short to get to the point where we want to be. So I would propose to still do a 0.19.0, make sure that all deprecations are in there, merge PRs quite aggressively for 0.19.0 as well, and then plan 1.0 as the next release (can be shorter than 6 months after 0.19.0). So maybe Nov/Dec for 0.19.0 and say March '17 for 1.0. Thoughts? Ralf [1] https://github.com/scipy/scipy/pull/2908 [2] https://mail.scipy.org/pipermail/scipy-dev/2013-September/019238.html [3] https://github.com/scipy/scipy/issues/6137
The timeline you suggest and the goals for signal sound good to me. I've been pretty tied up lately, and am traveling for the next two weeks, but after that I intend on attacking the filtering API (especially second order section support). Eric Q. On Sun, Sep 4, 2016 at 16:22 Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi all,
Starting with the summary of my email of earlier today: I'd like to pick a time for when we release SciPy 1.0, and what is still essential to do for that version number.
We've discussed this a couple of times before [1,2]. We're now at the point where most of the major gaps have been filled though, so it looks to me like it's time to just pick a date for it (either after or instead of 0.19.0) and then fix up the last things that we think we really need for a 1.0 release.
Here are the things that I see as essential: - Getting project organization in order: governance and CoC at least (see my other email of today). - scipy.signal: clean up the messes in wavelets and B-splines. - scipy.signal: unified filter API [3] - scipy.spatial: remove Python implementation of KDTree, just keep cKDTree - scipy.interpolate: not sure of the details, but I think there are some new interpolator classes and a spline PR that aren't quite finished? - Remove some deprecated items (weave is the biggest one), and decide now if there's anything else we need to deprecate. - Merge or close more PRs. We've stabilized them at around 120-130 open ones, but that's not really good enough if there are (almost) finished PRs that no one has looked at in a year. This may be the single biggest task.
We shouldn't make the above list too long, otherwise we won't get there. Really, SciPy is production quality software (with a few dusty corners), so we should limit ourselves to listing what is essential here.
Timing: I suspect that we want to deprecate some more things, and that 4 months is a little too short to get to the point where we want to be. So I would propose to still do a 0.19.0, make sure that all deprecations are in there, merge PRs quite aggressively for 0.19.0 as well, and then plan 1.0 as the next release (can be shorter than 6 months after 0.19.0). So maybe Nov/Dec for 0.19.0 and say March '17 for 1.0.
Thoughts?
Ralf
[1] https://github.com/scipy/scipy/pull/2908 [2] https://mail.scipy.org/pipermail/scipy-dev/2013-September/019238.html [3] https://github.com/scipy/scipy/issues/6137
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org https://mail.scipy.org/mailman/listinfo/scipy-dev
Starting with the summary of my email of earlier today: I'd like to pick a time for when we release SciPy 1.0, and what is still essential to do for that version number.
I'd think we should treat 1.0 as *almost* a usual release. It's not that by calling a release 1.0 instead of 0.20 or something we are going to freeze everything. It seems that we already have a healthy deprecation policy, so we might consider extending the deprecation periods, but that seems to be more or less it.
Here are the things that I see as essential: - Getting project organization in order: governance and CoC at least (see my other email of today). - scipy.signal: clean up the messes in wavelets and B-splines. - scipy.signal: unified filter API [3] - scipy.spatial: remove Python implementation of KDTree, just keep cKDTree - scipy.interpolate: not sure of the details, but I think there are some new interpolator classes and a spline PR that aren't quite finished?
Not sure there are unfinished new interpolator classes apart from Pauli's rational interpolation PR. Which I'd label as a very-nice-to-have, but not a blocker. The spline PR is nearly ready. It mainly needs some more review and user testing (and a small amount of work to tweak the interface to be consistent with newer additions from 2016). The PR itself is fairly straightforward, but it just touches *a lot* of legacy code, so it's potentially disruptive.
- Remove some deprecated items (weave is the biggest one), and decide now if there's anything else we need to deprecate. - Merge or close more PRs. We've stabilized them at around 120-130 open ones, but that's not really good enough if there are (almost) finished PRs that no one has looked at in a year. This may be the single biggest task.
+1 for this. I also agree it's better to keep this list short. I would, however, add to this list of high-priority items also Pauli's LowLevelFunction, https://github.com/scipy/scipy/pull/6509.
We shouldn't make the above list too long, otherwise we won't get there. Really, SciPy is production quality software (with a few dusty corners), so we should limit ourselves to listing what is essential here.
Timing: I suspect that we want to deprecate some more things, and that 4 months is a little too short to get to the point where we want to be. So I would propose to still do a 0.19.0, make sure that all deprecations are in there, merge PRs quite aggressively for 0.19.0 as well, and then plan 1.0 as the next release (can be shorter than 6 months after 0.19.0). So maybe Nov/Dec for 0.19.0 and say March '17 for 1.0.
Either this, or skip 0.19.0 and just release 1.0 in March or so. The only thing I'd watch out for is that we likely want to avoid having three active branches (maintenance/0.19.x, maintenance/1.0.x and master) for an extended period of time. IOW, if we do release 0.19.0, we need keep in mind 0.19.1 before branching 1.x. Or maybe we can ask matplotlib people about managing their 1.5.x, 2.0.x and master branches. Cheers, Evgeni
On Tue, Sep 6, 2016 at 7:09 AM, Evgeni Burovski <evgeny.burovskiy@gmail.com> wrote:
Starting with the summary of my email of earlier today: I'd like to pick a time for when we release SciPy 1.0, and what is still essential to do for that version number.
I'd think we should treat 1.0 as *almost* a usual release. It's not that by calling a release 1.0 instead of 0.20 or something we are going to freeze everything. It seems that we already have a healthy deprecation policy, so we might consider extending the deprecation periods, but that seems to be more or less it.
Indeed, that's what I was thinking. Thanks for spelling it out:)
Here are the things that I see as essential: - Getting project organization in order: governance and CoC at least (see my other email of today). - scipy.signal: clean up the messes in wavelets and B-splines. - scipy.signal: unified filter API [3] - scipy.spatial: remove Python implementation of KDTree, just keep cKDTree - scipy.interpolate: not sure of the details, but I think there are some new interpolator classes and a spline PR that aren't quite finished?
Not sure there are unfinished new interpolator classes apart from Pauli's rational interpolation PR. Which I'd label as a very-nice-to-have, but not a blocker.
The spline PR is nearly ready. It mainly needs some more review and user testing (and a small amount of work to tweak the interface to be consistent with newer additions from 2016). The PR itself is fairly straightforward, but it just touches *a lot* of legacy code, so it's potentially disruptive.
- Remove some deprecated items (weave is the biggest one), and decide now if there's anything else we need to deprecate. - Merge or close more PRs. We've stabilized them at around 120-130 open ones, but that's not really good enough if there are (almost) finished PRs that no one has looked at in a year. This may be the single biggest task.
+1 for this.
I also agree it's better to keep this list short. I would, however, add to this list of high-priority items also Pauli's LowLevelFunction, https://github.com/scipy/scipy/pull/6509.
That would be good indeed.
We shouldn't make the above list too long, otherwise we won't get there. Really, SciPy is production quality software (with a few dusty corners), so we should limit ourselves to listing what is essential here.
Timing: I suspect that we want to deprecate some more things, and that 4 months is a little too short to get to the point where we want to be. So I would propose to still do a 0.19.0, make sure that all deprecations are in there, merge PRs quite aggressively for 0.19.0 as well, and then plan 1.0 as the next release (can be shorter than 6 months after 0.19.0). So maybe Nov/Dec for 0.19.0 and say March '17 for 1.0.
Either this, or skip 0.19.0 and just release 1.0 in March or so.
That works too, if there are no deprecations to be made of stuff we want to remove by 1.0. I'm not sure that there are. The signal splines would be nice to get rid of, but having them sit around deprecated is also not a problem.
The only thing I'd watch out for is that we likely want to avoid having three active branches (maintenance/0.19.x, maintenance/1.0.x and master) for an extended period of time. IOW, if we do release 0.19.0, we need keep in mind 0.19.1 before branching 1.x. Or maybe we can ask matplotlib people about managing their 1.5.x, 2.0.x and master branches.
If we don't make radical/breaking changes for 1.0 (which is not the plan I think), there's also no strong reason to keep the last pre-1.0 branch as a long-lived maintenance branch I'd say. Ralf
participants (3)
-
Eric Q -
Evgeni Burovski -
Ralf Gommers