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

[Eric Firing]

Brian Granger wrote:
> Hi,
> 
> As Fernando mentioned, we are considering moving to a time-based
> released process with IPython1.  Obviously, IPython1 is a very
> different project than numpy, but I figured it might be useful to
> state some of the other reasons we are thinking about going this
> direction:
> 
> 1.  It stops feature creep - "oh, just this one more thing and then we
> will release"  We really struggle with this in IPython1.
> 
> 2.  It is a way of saying to the community regularly "this project is
> not dead, we are fixing bugs and adding new features all the time."
> For those of us who follow the lists, this is not as big of a deal,
> but _many_ users are not on the lists.  When they see that there
> hasn't been a release in 6 months, what do they think?  This is
> marketing.
> 
> 3.  It gets bug fixes and better tested code into users hands sooner.
> Think of all the bugs that have been fixes since 1.0.4 was released in
> November!

This is a major point, and it has related aspects:

3a) The only way to get code fully tested is to get it out and in use. 
People have to try it in real life.  There are severe limits to what 
unit testing can accomplish.  A combination of something like daily (or 
weekly) builds and more frequent scheduled releases would facilitate 
more effective testing, and would give people more time to find out what 
works and what breaks, what we need to fix and what they will need to 
change.

3b) The above is one of the reasons I favored merging the new MA 
implementation--it needed more exposure, and there seemed to be no other 
mechanism to get it--but the other is that given the uncertainty 
regarding release timing it looked like practically "now or never". 
With a release cycle and a policy for changes in place, the merge could 
have been planned better and started earlier.

I am very sympathetic to the argument for stability, but it has to be 
balanced against the need for genuine improvement and maintenance, and 
against the developers' time burden associated with maintaining multiple 
versions, or support for multiple versions.

> 
> 4.  It gives developers regular deadlines which (hopefully) motivates
> them to contribute code more regularly.
> 
> An aside (this holds true for Numpy, Scipy and IPython):  I have
> noticed that all of these projects are very slow to bump up the
> version numbers (for example, IPython0 is only at 0.8.x).  I think
> this is unfortunate because it leaves us with no choice but to have
> API breakage + huge new features in minor releases.  Why not be more
> bold and start the up the version numbers more quickly to reflect that
> lots of code is being written?  My theory - we are all perfectionists
> and we are afraid to release NumPy 2.0/SciPy1.0/IPython0-1.0 because
> we know the code is not perfect yet.  I think Sage (they are > 3.0 at
> this point and started long after scipy/numpy/ipython) is a great
> counterexample of a project that is not afraid to bump the version
> numbers up quickly to reflect fast moving code.  My two cents.

All good points.  Thank you.

Eric
> 
> Cheers,
> 
> Brian
> 
> 
> On Sun, May 11, 2008 at 8:59 PM, David Cournapeau
> <cournapeau at cslab.kecl.ntt.co.jp> wrote:
>> Hi,
>>
>>         I would like to know how people feel about going toward a time-based
>>  release process for numpy (and scipy). By time-based release, I mean:
>>         - releases of numpy are time-based, not feature based.
>>         - a precise schedule is fixed, and the release manager(s) try to
>>  enforce this schedule.
>>
>>  Why ? I already suggested the idea a few months ago, and I relaunch the
>>  idea because believe the recent masked array + matrix issues could have
>>  been somewhat avoided with such a process (from a release point of view,
>>  of course). With a time-based release, there is a period where people
>>  can write to the release branch, try new features, and a freeze period
>>  where only bug fixes are allowed (and normally, no api changes are
>>  allowed). Also, time-based releases are by definition predictable, and
>>  as such, it is easier to plan upgrades for users, and to plan breaks for
>>  developers (for example, if we release say every 3 months, we would
>>  allow one or two releases to warn about future incompatible changes,
>>  before breaking them for real: people would know it means 6 months to
>>  change their code).
>>
>>  The big drawback is of course someone has to do the job. I like the way
>>  bzr developers do it; every new release, someone else volunteer to do
>>  the release, so it is not always the same who do the boring job.
>>
>>  Do other people see this suggestion as useful ? If yes, we would have to
>>  decide on:
>>         - a release period (3 months sounds like a reasonable period to me ?)
>>         - a schedule within a release (api breaks would only be allowed in the
>>  first month, code addition would be allowed up to two months, and only
>>  bug fixes the last month, for example).
>>         - who does the process (if nobody steps in, I would volunteer for the
>>  first round, if only for seeing how/if it works).
>>
>>  cheers,
>>
>>  David
>>
>>  _______________________________________________
>>  Numpy-discussion mailing list
>>  Numpy-discussion at scipy.org
>>  http://projects.scipy.org/mailman/listinfo/numpy-discussion
>>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion