On Sun, 2008-05-11 at 21:14 -0700, Mike Ressler wrote: > > I'm just a common user, but please, no. The big Linux distros do this > and it drives me nuts. Just when things are finally beginning to > settle down, they throw another big, buggy release out the door > because they are trying to meet some ridiculous 6 month cycle. "We" > haven't even gotten the major distros to dump Numeric-24 yet > (something else depends on it - pygtk maybe?), though most offer numpy > as an option; what kind of disaster will we have with new numpy > releases every 3 or 6 months?
I don't see what you mean by disaster. The point of having a time-based release is to avoid bugs caused by putting new, untested things late in the release (like what is happening for 1.1 with ma/matrix), and to be able to plan those changes. I personally would really like to avoid the recent matrix thing: just when 1.1 was about to be released, several months late already, a new change which broke many things was introduced. If we keep doing that, things will become unmanageable. > > Numpy doesn't (and probably shouldn't) change that rapidly. I would > really hope that the core numpy is solid, stable, and predictable. I > like major and minor version numbers that indicate a major change is > coming. If it's only a minor version number change, I know that I can > update it safely and go merrily computing on my way. "2008.04" doesn't > tell me if it is a minor bug fix or a major blow to my sanity. Time-based release has nothing to do with the way we version releases per-se: we would still call every numpy release with the current versioning. Also, make the release process predictable is exactly the point of time-based release: it means we can have a policy for api changes, and code freeze policies (which really should not change that often as has happened the last few months). cheers, David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
