You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A recent change to url has caused openblas-src's MSRV to bump to 1.67 (when using most recent dependencies). While this doesn't affect ndarray directly, it does affect the clarity and interoperability of ndarray with a major BLAS provider and raises an important question: should ndarray have an MSRV policy and, if yes, what should that policy be?
This question breaks down into three parts:
Should ndarraypromise a certain MSRV? (This means listing a rust-version in the Cargo.tomland pinning any necessary dependencies in patch versions to ensure that rust-version is maintained)
If ndarray does promise an MSRV, what should be the policy for which MSRV is guaranteed? For example, two years (the approximate MSRV right now) vs two versions.
When ndarray bumps its MSRV, is that a patch update, or a minor version update?
I would like to solicit feedback on this topic from users of ndarray. If you use ndarray, what is your usual Rust configuration? Are you running on the most recent version, or something older?
MSRV and its association with versioning is a much, much larger conversation. If possible, I would like to keep any conversation to just what ndarray's policy should be; not what the wider ecosystem does.
My personal preference is that ndarraydoes promise a recent MSRV, and that updates to that MSRV occur only in minor version updates.
Activity
bluss commentedon Nov 22, 2024
Current docs say 'MSRV: Requires Rust 1.64 or later', which I thought has to be mentioned.
akern40 commentedon Nov 23, 2024
Absolutely - when I talk about a "policy", I'm just asking about how and when we decide to bump the MSRV. How have you made this decision in the past?