[Numpy-discussion] Going toward time-based release ?
Mon May 12 11:47:35 CDT 2008
On Mon, May 12, 2008 at 5:31 AM, Joris De Ridder
> As long as it does not imply that users have to upgrade every 3
> months, because for some users this is impossible and/or undesirable.
> By 'upgrading' I'm not only referring to numpy/scipy, but also to
> external packages based on numpy/scipy.
I can't imagine why anyone would have to upgrade. Could you explain
under what circumstances you would see having to upgrade just because
their is a new upstream release? I think I must be misunderstanding
> As Mike, I'm a bit sceptic about the whole idea. The current way
> doesn't seem broken, so why fix it? The argument that "time-based
> releases avoids bugs caused by putting new untested things late in the
> release" doesn't sound very convincing to me. Isn't this a discipline
> issue? To me it seems that one can avoid this with feature-based
> releases too. In fact won't the time-pressure of time-based releases
> increase the tendency to include untested things?
As a data point, I have to say that I view the current process as a
bit broken. I have been very frustrated trying to get this latest
release out and if you remember the reason I took over release
management last summer was that the current release of NumPy and SciPy
didn't work together for several months prior to me releasing 18.104.22.168
and 0.5.2.1. I am a little surprised that anyone would believe that
the current system isn't broken.
Now I don't think that that means the solution is to move to a
time-based release schedule necessarily. But since I was hoping to do
something like a time-based release for 1.2 anyway, I am happy to try
it and see how it works. The concern is obviously not to include
untested things; but no one wants to do that. If we get to the end of
the 3 months and can't release a stable, well-tested release by using
the trunk or by discarding some features, I think we would just
consider the experiment a failure. There is nothing to force us to
release untested code.
If you look at the people in favor of this, you will find they are
also some of the most adamant voices about including unit tests for
all new code as well. So I don't believe any of us will require that
we release 1.2 at the end of three months regardless of the quality.
The more likely scenario is that those of us supporting this idea will
be able to use the time-based release cycle as a mechanism to ensure
high-quality, well-tested code is produced. Again it this experiment
fails, we should know before we actually make the release.
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
More information about the Numpy-discussion