Working on ndarray 0.16.0

[bluss]

Hi, I think we could release version 0.16.0 soon.

There are some breaking changes - very minor, related to some functions changing type parameters.
It would be good to make a release to get the changes in master published.
Perfect would be if we had the bandwidth to put the non-breaking changes into a final release in the 0.15.x branch, but I think we should skip perfect for now.

We also have breaking changes planned in the future - adopting const generics further, starting very simple by just translating what we have without adding much of new features.

I wanted to ask @adamreichold how it impacts you - and also any others that are interested - because it can be painful to coordinate updates.

[adamreichold]

I have to check if anything in rust-numpy is affected. Will do so ASAP. Ideally we'll just enlarge the interval of supported versions of ndarray and then I could ship that as a point release in the 0.21.x series.

[adamreichold]

Ok, everything seems to work against the master branch here, so extending the interval of supported versions should work.

The main obstacle I currently have is that we ship an example based on ndarray-linalg and hence I would either need a matching release of that crate or apply the above dependency wrangling so that this particular example continues to build against the older version.

[bluss]

Thanks for checking. I don't have a solution for ndarray-linalg right now.

[adamreichold]

ndarray-linalg would not be a blocker for me. I can just continue to build that particular example against ndarray 0.15.6 since that we still be supported. I think I will only need to check in a Cargo.lock file to make this work which has become recommended by now in any case.

[bluss]

This old fix - #994 - which is "for" rust-numpy - would be a breaking change for you. It's on my to do list to hopefully include in the release. We'd like to include it but maybe we can add it without breaking into_raw_vec, instead adding another method.

I've updated it to be a deprecation, not a breaking change.

[adamreichold]

Thank you for explicitly considering our needs as a downstream project! Going via the deprecation would certainly be nice as it would enable us to keep enlarging the list of supported versions.

Admittedly, this will be a bit of simplification since we can delete the layout-dependent code from our code base when we switch to the new method, but I will probably not jump on that bandwagon in 0.16 but rather 0.17 (and eat the deprecation until them) to give users more time to migrate off older ndarray versions (they explicitly asked for keeping them supported in the past).