On Sun, 2008-05-11 at 21:26 -0700, Jarrod Millman wrote: > > The one caveat to this is that you may recall I have tried to start > having a 3 month release cycle ever since I took over release > management last summer. I was almost able to do it for the first > release of NumPy and SciPy. But since November of last year, I have > been struggling to get out NumPy 1.1, which was originally scheduled > for early February.
My impression, but maybe I am missing something, is that the release slipped because everybody added new code. If we have a strict policy to say no new code, only bug fixes at least for 2 weeks before a release (and even no changes at all for a period), the release process becomes much easier, no ? IMHO, the main advantage of time-based release is to be able to say no to new code just before release, and to be able to say that an api breaks cannot happen between two releases: any change needs at least N releases in between with warnings, and we know what N means because N * release period is the time you have to make changes if you want to stay up to date. I personally really did not like what happened with ma and matrix in the 1.1, and I would like to avoid this in the future. It is already pretty bad to break code in a minor release, but to do it without warnings is really something which should never happen again IMHO. cheers, David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
