On Tue, Jun 26, 2012 at 8:15 PM, Skipper Seabold <[email protected]> wrote: > On Tue, Jun 26, 2012 at 7:59 PM, Fernando Perez <[email protected]> wrote: >> On Tue, Jun 26, 2012 at 1:10 PM, Travis Oliphant <[email protected]> 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 > [email protected] > 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 _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
