[Numpy-discussion] Going toward time-based release ?

David Cournapeau cournapeau@cslab.kecl.ntt.co...
Mon May 12 01:59:09 CDT 2008

On Mon, 2008-05-12 at 00:39 -0600, Charles R Harris wrote:

> Which makes the spot where a gets initialized almost invisible. It is
> amazing how much easier the code is to read and understand with these
> simple changes. But if we plan tasks for the release, then we also
> have to assign people to the task. That is where it gets sticky.

That's exactly why I am suggesting a time-based release; that's the kind
of  stuff I want to see in numpy (< 2.* ) and scipy (< 1.*). The way I
saw things was: it is ok to do this kind of changes, but only N days
before the official release. After this point, the only (and I really
mean only) reason is a critical bug. It is really easy to think "hey,
let's do this one line change, that can't possibly break anything,
right ?", and two days after: "hey, this breaks on windows because VS
does not recognize this code". If between the two days, you have
released numpy, you're screwed.

Doing this with a time schedule is easier, I think.

FWIW, I am doing exactly this for scipy.fftpack right now, and that's a
lot of relatively boring work (fftpack is a bit special because it has a
big list of possible combination dependencies with different code paths,
and testing all of them is painful, but doing this in numpy.core is not
that much easier).



More information about the Numpy-discussion mailing list