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

[Jarrod Millman]

On Sun, May 11, 2008 at 9:14 PM, Mike Ressler <mike.ressler at alum.mit.edu> 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/