[SciPy-dev] scipy.optimize.nonlin rewrite

David Cournapeau david@ar.media.kyoto-u.ac...
Mon Dec 1 06:46:41 CST 2008

Stéfan van der Walt wrote:
> 2008/12/1 David Cournapeau <cournape@gmail.com>:
>> first beta. Also, rushing to add new code may lead to oversight some
>> limitation, some API bug, etc...
> I'm happy to postpone, but then we should accept that the API may
> change just after 0.7.  It concerns me that non-reviewed code becomes
> the standard quo, and then sets the API for the future.

Hey, that's one of the reason why I prefer avoiding changes during the
beta timeline :) By rushing code into the release, we are less likely to
review changes correctly; from the discussion, it looks quite likely
that the rewrite is not ready yet.

The only goal of a beta is to see whether we have unexpected failures,
and solve them until the release. If we add new code, there is no point
in doing beta. Even without taking into account this, having a window
where no new feature is allowed is a really common process; even linux,
which changes extremely rapidly, has a limited time window for merges.
Every project with a proper release management enforce those very
strictly, because that's the whole point, really. Otherwise, releases
are nothing more than a snapshot of the source code at a given time

The problem of people not seeing their code quickly should be solved by
doing more frequent releases IMO; "freezing" the trunk for some time
before releases helps that, rushing new code does not. It is not
theoretical: almost all my time spent on scipy the last few weeks have
been related to recently added code.



More information about the Scipy-dev mailing list