On Sun, May 11, 2008 at 9:42 PM, Robert Kern <[EMAIL PROTECTED]> 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/ _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion