[Numpy-discussion] Created NumPy 1.7.x branch

[Fernando Perez]

On Tue, Jun 26, 2012 at 10:25 PM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
>
> On Tue, Jun 26, 2012 at 5:33 AM, Travis Oliphant <travis at 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