On Tue, Jun 26, 2012 at 10:25 PM, Ralf Gommers <ralf.gomm...@googlemail.com> wrote: > > On Tue, Jun 26, 2012 at 5:33 AM, Travis Oliphant <tra...@continuum.io> > wrote: > ... >> >> What should have happened in this case, in my mind, is that NumPy 1.4.0 >> should have been 1.5.0 and advertised that there was a break in the ABI and >> that all extensions would have to be re-built against the new version. >> This would have been some pain for one class of users (primarily package >> maintainers) and no pain for another class. > > > Please please stop asserting this. It's plain wrong. It has been explained > to you multiple times by multiple people how bad the consequences of > breaking the ABI are. It leads to random segfaults when existing installers > are not updated or when users pick the wrong installer by accident (which > undoubtedly some will). It also leads to a large increase in the number of > installers that maintainers for every single package that depends on numpy > will have to build. Including for releases they've already made in the past.
An additional perspective on the issue of ABI breakage: even for those of us who live in a distro-managed universe (ubuntu in my case), the moment numpy breaks ABI means that it becomes *much* harder to use the new numpy because I'd have to start recompiling all binary dependencies, some of which are not pleasant to start rebuilding (such as VTK for mayavi). So that means I'm much less likely to use an ABI-incompatible numpy for everyday work, and therefore less likely to find bugs, report them, etc. I typically run dev versions of numpy, scipy and matplotlib all the time, except when numpy breaks ABI, which means I have to 'pin' numpy to the system one and only update the others. Now, obviously that doesn't mean that ABI can never be broken, but it's just another data point for you as you evaluate the cost of ABI breakage. It is significant even for those who operate under the benefit of managed packages, because numpy is effectively the root node of the dependency tree for virtually all scientific python packages. I hope this is useful as additional data on the issue. Cheers, f _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion