[Numpy-discussion] Going toward time-based release ?
Mon May 12 14:00:31 CDT 2008
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
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
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
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.
On Sun, May 11, 2008 at 8:59 PM, David Cournapeau
> 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).
> Numpy-discussion mailing list
More information about the Numpy-discussion