[SciPy-Dev] Timing of SciPy 1.0

[Ralf Gommers]

On Tue, Sep 6, 2016 at 7:09 AM, Evgeni Burovski <evgeny.burovskiy at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160906/500ae2ec/attachment.html>