[Numpy-discussion] Created NumPy 1.7.x branch
Mon Jun 25 23:12:19 CDT 2012
On Tue, Jun 26, 2012 at 4:42 AM, Ondřej Čertík <firstname.lastname@example.org> wrote:
> On Mon, Jun 25, 2012 at 8:35 PM, David Cournapeau <email@example.com> wrote:
>> On Tue, Jun 26, 2012 at 4:10 AM, Ondřej Čertík <firstname.lastname@example.org> wrote:
>>> My understanding is that Travis is simply trying to stress "We have to
>>> think about the implications of our changes on existing users." and
>>> also that little changes (with the best intentions!) that however mean
>>> either a breakage or confusion for users (due to historical reasons)
>>> should be avoided if possible. And I very strongly feel the same way.
>>> And I think that most people on this list do as well.
>> I think Travis is more concerned about API than ABI changes (in that
>> example for 1.4, the ABI breakage was caused by a change that was
>> pushed by Travis IIRC).
>> The relative importance of API vs ABI is a tough one: I think ABI
>> breakage is as bad as API breakage (but matter in different
>> circumstances), but it is hard to improve the situation around our ABI
>> without changing the API (especially everything around macros and
>> publicly accessible structures). Changing this is politically
>> difficult because nobody will upgrade to a new numpy with a different
>> API just because it is cleaner, but without a cleaner API, it will be
>> difficult to implement quite a few improvements. The situation is not
>> that different form python 3, which has seen a poor adoption, and only
>> starts having interesting feature on its own now.
>> As for more concrete actions: I believe Wes McKinney has a
>> comprehensive suite with multiple versions of numpy/pandas, I can't
>> seem to find where that was mentioned, though. This would be a good
>> starting point to check ABI matters (say pandas, mpl, scipy on top of
>> multiple numpy).
> I will try to check as many packages as I can to see what actual problems
> arise. I have created an issue for it:
> Feel free to add more packages that you feel are important. I will try to check
> at least the ones that are in the issue, and more if I have time. I will
> close the issue once the upgrade path is clearly documented in the release
> for every thing that breaks.
I believe the basis can be 1.4.1 against which we build different
packages, and then test each new version.
There are also tools to check ABI compatibility (e.g.
http://ispras.linuxbase.org/index.php/ABI_compliance_checker), but I
have never used them. Being able to tell when a version of numpy
breaks ABI would already be a good improvement.
More information about the NumPy-Discussion