[Numpy-discussion] Going toward time-based release ?
Sun May 11 23:35:58 CDT 2008
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).
More information about the Numpy-discussion