[SciPy-Dev] preparing for scipy 0.8 release

[Ralf Gommers]

<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
<ralf.gommers at googlemail.com>wrote:

>
>
> On Mon, Apr 26, 2010 at 6:44 AM, Pauli Virtanen <pav+sp at iki.fi<pav%2Bsp at 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 decompositions,
>>  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!
>>
>> * http://github.com/pv/scipy-work/tree/ticket/791-optimize-nonlin-rewrite
>>
>>  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 scipy.special
>>  bugs.
>>
>
> 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 snapshot
>> > binaries in June.
>>
>> As David said, we'll need at least Numpy >= 1.4, due to use of npymath.
>>
>> It might be difficult to go for Python 3 support if we want to have
>> 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 maintain
>> 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
compatibility
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?

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100428/74cfd337/attachment.html>