[Numpy-discussion] NumPy 1.7 release delays
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
> +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.
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
+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).
More information about the NumPy-Discussion