Description
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
ndarray
promise a certain MSRV? (This means listing arust-version
in theCargo.toml
and pinning any necessary dependencies in patch versions to ensure thatrust-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 ndarray
does promise a recent MSRV, and that updates to that MSRV occur only in minor version updates.