[Numpy-discussion] NumPy 1.7 release delays

Wes McKinney wesmckinn at gmail.com
Tue Jun 26 20:37:42 EDT 2012

On Tue, Jun 26, 2012 at 8:15 PM, Skipper Seabold <jsseabold at gmail.com> wrote:
> On Tue, Jun 26, 2012 at 7:59 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>> On Tue, Jun 26, 2012 at 1:10 PM, Travis Oliphant <travis at continuum.io> wrote:
>>> One issues is the one that Sage identified about the array interface
>>> regression as noted by Jason.    Any other regressions from 1.5.x need to be
>>> addressed as well.    We'll have to decide on a case-by-case basis if there
>>> are issues that conflict with 1.6.x behavior.
>> One thing this discussion made me think about, is that it would be
>> great to identify a few key projects that:
>> - use numpy heavily
>> - have reasonably solid test suites
>> and create a special build job that runs *those* test suites
>> periodically.  Not necessarily on every last numpy commit, but at
>> least on a reasonable schedule.
>> I think having that kind of information readily available, and with
>> the ability to switch which numpy branch/commit those tests do get run
>> against, could be very valuable as an early warning system for numpy
>> to know if an apparently inconsequential change has unexpected side
>> effects downstream.
>> In IPython we've really benefited greatly from our improved CI
>> infrastructure, but that only goes as far as catching *our own*
>> problems.  This kind of downstream integration testing could be very
>> useful.
> +1. Was thinking the same thing.
> My uninformed opinion from the sidelines: For me, this begged the
> question of why projects would wait so long and be upgrading 1.5.x ->
> 1.7.x. it sounded to me like an outreach problem. The whole point of
> having release candidates is so that downstream users (and especially
> big public downstream libraries) can test the release candidate and
> give feedback on any changes that affect them. This feedback step is
> especially crucial for a project without 100% test coverage (for new
> code and old)... Putting more restrictions on changes that can be made
> in releases doesn't seem to me to be the right fix, though,
> admittedly, numpy is a bit of a different beast than other projects. I
> would think you would want downstream projects not to wait 2 years to
> upgrade and skip a couple of minor releases.
> Skipper
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

+1. We've begun running pandas's test suite internally against NumPy
git master on Jenkins. It has already turned up bugs and behavior
changes in a few short weeks. We should definitely do this on a more
grand scale (especially since pandas 0.8.0 is now littered with hacks
around NumPy 1.6 datetime bugs. fortunately nothing was fatally broken
but it came close).

- Wes

More information about the NumPy-Discussion mailing list