[SciPy-Dev] preparing for scipy 0.8 release
Wed Apr 28 11:08:21 CDT 2010
On 04/28/2010 08:04 AM, Ralf Gommers wrote:
> <resending because mail server seems to have swallowed it the first
> time. apologies if you get it twice.>
> On Mon, Apr 26, 2010 at 7:41 PM, Ralf Gommers
> <email@example.com <mailto:firstname.lastname@example.org>> wrote:
> On Mon, Apr 26, 2010 at 6:44 AM, Pauli Virtanen <email@example.com
> <mailto:pav%2Bsp@iki.fi>> wrote:
> Sun, 25 Apr 2010 19:05:27 +0800, Ralf Gommers wrote:
> > Now that scipy 0.7.2 and numpy 1.4.1 are out the door, it's
> time to look
> > at what needs to be done for scipy 0.8.
> > Some questions
> > - What needs to be done and what do you all want included
> that's not in
> > trunk yet in terms of features / new code / code cleanups?
> I have these on my platter:
> * http://github.com/pv/scipy-work/tree/superlu-update
> SuperLU 4.0, which includes support for incomplete LU
> which at least I've been really missing in Scipy.
> New feature: scipy.sparse.linalg.spilu
> Needs just some tests, otherwise done. So if someone wants to
> test it
> or write some tests exercising splu and spilu, that'd be helpful!
> New feature: scipy.optimize.nonlin rewrite
> Quite done, and with tests. However, scipy.optimize line
> searches take
> a ~20% performance hit because of the way I refactored them.
> If this
> doesn't sound good, I can try to rework it still more.
> * Might be also nice to fix the remaining most serious
> So merging/fixing this in the next month is feasible for you?
> > - Right now scipy trunk needs to be built against numpy
> trunk. Is it
> > feasible to build against numpy 1.3 still, to get one
> > backwards-compatible release?
> > If not, 0.8 should be released in parallel with numpy 2.0. -
> Time line:
> > do we want a release before SciPy2010 (end of June)? If so,
> there's only
> > a month left before a freeze. If not, we could just provide
> > binaries in June.
> As David said, we'll need at least Numpy >= 1.4, due to use of
> It might be difficult to go for Python 3 support if we want to
> backwards compatibility with Numpy 1.4, unless we go really
> ugly and
> start duplicating some of the utility functions inside Scipy.
> But from a
> maintenance POV that might be less of a burden than having to
> 0.8.x and 0.9.x simultaneously...
> The number of fixes in the 0.7 series is small, so I'm not sure if
> the maintenance burden is really that high (besides possibly
> having to do an extra maintenance release). It depends on how long
> you'd want to keep compatibility with numpy 1.4. Anyway, both
> options sound better than having no compatible release at all.
> I thought about it some more, and a backwards compatible release with
> numpy 1.4.1 that is also compatible with numpy 2.0 is not even
> possible. And compatibility with 1.4.0 is not nearly as useful. So two
> releases would really make sense: 0.8 built against numpy 1.4.1 and
> 0.9 against numpy 2.0 with py3k compatibility.
> Here's a proposal for the release schedule:
> 30/05: create 0.8.x branch, beta available, trunk open to add py3k
> 11/06: 0.8 release candidate 1
> 22/06: 0.8 release
> 15/08: create 0.9.x branch, first beta
> 22/08: 0.9 release candidate 1
> 01/09: 0.9 release
> How does this sound?
Why so slow for the 0.8 branch?
I would say create the branch now or as soon as possible once you
identify what features need to go into it. I think it is important to
have a numpy 1.4 compatible build available so that we minimize bug
reports that we know are fixed.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SciPy-Dev