hi, even if it are good changes, I find it reasonable to ask for a delay in numpy release if you need more time to adapt. Of course this has to be within reason and can be rejected, but its very valuable to know changes break existing old workarounds. If pyfits broke there is probably a lot more code we don't know about that is also broken. Sometimes we might even be able to get the good without breaking the bad. E.g. thanks to Sebastians heroic efforts in his recent indexing rewrite only very little broke and a lot of odd stuff could be equipped with deprecation warnings instead of breaking. Of course that cannot often be done or be worthwhile but its at least worth considering when we change core functionality. cheers, Julian On 31.01.2016 22:52, Marten van Kerkwijk wrote:
Hi Julian,
While the numpy 1.10 situation was bad, I do want to clarify that the problems we had in astropy were a consequence of *good* changes in `recarray`, which solved many problems, but also broke the work-arounds that had been created in `astropy.io.fits` quite a long time ago (possibly before astropy became as good as it tries to be now at moving issues upstream and perhaps before numpy had become as responsive to what happens downstream as it is now; I think it is fair to say many project's attitude to testing has changed rather drastically in the last decade!).
I do agree, though, that it just goes to show one has to try to be careful, and like Nathaniel's suggestion of automatic testing with pre-releases -- I just asked on our astropy-dev list whether we can implement it.
All the best,
Marten