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

[Jarrod Millman]

On Sun, May 11, 2008 at 9:42 PM, Robert Kern <robert.kern at gmail.com> wrote:
> The semantics of major.minor.micro for numpy got confused because of
> an early mistake (IMO) wherein we designated 1.1 as a release which
> would allow code breakage.

I disagree.  I didn't realize that the ma change was going to break
anyone's code.  Once I understood that it did I decided to call the
release 1.1.0 rather than 1.0.5.  I think that it is reasonable to
allow some API breakage in a minor release, but that there is no
reason to encourage it and we should absolutely not require it.  The
problem as I see it is that we were abusing the maintenance releases
to add a significant number of features, rather than just simply
fixing bugs.

> I would very much like to get away from
> that and follow Python's model of only doing bugfixes/doc-enhancements
> in micro releases, new features in minor releases and code breakage
> never (or if we absolutely must, only after one full minor release
> with a deprecation warning).

+1
I absolutely agree.  David and I will help make sure this is the case
moving forward.  At some point, if no one else gets to it, I will
write this up more formally and make sure it is available on the scipy
website.

> I think it is certainly feasible to roll out the bugfix releases on a
> fixed schedule. I am less certain about the feature releases; I'm not
> sure we gain much by it. Having a feature freeze policy is sufficient,
> IMO. Once we've decided that we have accumulated enough features for a
> release, we declare a feature freeze for a fixed period of time,
> test/build/bugfix, then release. I think a fixed recurring time period
> may simply encourage rushing features in without testing.

I am in favor of a compromise.  We aim for a time-based release and
are realistic about what new features we accept for a release.  We
institute a soft-feature freeze two months before the release and a
hard feature freeze one month before the release.  We can let the
release slip a few weeks, but no more.  To assure that our releases
our solid, we may have to pull features before the release.

In order to facilitate this, each major new feature will have an
assigned lead who is responsible for overseeing the features
development.  In addition to helping guide the feature's development,
the assigned lead will be required to remove the feature if necessary.
 The lead will be required to evaluate the features progress at the
two month, one month, and release mark.

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/