On Sun, May 11, 2008 at 9:14 PM, Mike Ressler <[EMAIL PROTECTED]> 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?
This is a somewhat separate issue. I completely agree that we should take a very conservative approach to changing our API, but I would still like to see regular releases even if there was no API change. So it would be fine for me to have maintenance or minor release every three months. We should also have very few (if any) API changes if possible. That said, I expect to see more changes to SciPy than NumPy. > 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. We use the standard major.minor.maintenance numbering scheme and will do so regardless of whether we move from a feature-based to a time-based release cycle. Your points are completely relevant and I entirely agree with you. The one point to be clarified is that minor numbers signify that there may be some API breakage. The traditional meaning is something like: 1. a change in the maintenance number means just bug-fixes, better documentation, and possibly some very trivial feature addition. 2. a change in the minor number means there may be very minor API breakage, major new features, bug-fixes, and better documentation. 3. a change in the major number means there may be major API changes. A minor number should require very trivial modification of existing code, while a major number may signify that user's may require rewriting their code. However, it is never a good idea to break API unless the alternative is worse. Most of the developers are extremely reluctant to break user's code. > So, please, if at all possible, keep the feature numbering. Thanks for > hearing me out. Thanks for giving us your input. Without knowing what our user's want, we run the risk of becoming irrelevant so please don't hesitate to pitch in where and whenever possible. Of course, we can always use help with code, documentation, and testing as well. Thanks, -- 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
