[SciPy-Dev] Timing of SciPy 1.0

[Evgeni Burovski]

> 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