Supported versions of array libraries

[ev-br]

For numpy, we test against numpy 1.22, 1.26, "latest" and "dev".
For other array libraries (torch, cupy, dask) do not specify the version, and effectively test with whatever pip installs for a given python version.
Are we happy with this, or do we want to specify a lower limit for torch and cupy, too?

Case in point: CuPy merges an array-api compatible fix for 14.0. When 14.0 is out, do we

• keep testing with 13.x and 14.x (hence carry a workaround for 13.x in array-api-compat/cupy), or
• just test against 14.x (hence no need for a workaround in array-api-compat/cupy)

I suppose the deciding factor here is what downstream consumers support.

[rgommers]

Making the lowest version that is the lower one of (a) what was released in the last 12 months, and (b) whatever major consumers of array-api-compat actually need would be a reasonable way to go I think. Whether that needs test coverage: probably yes, but perhaps not in all cases.

[betatim]

I think because array-api-compat is about compatibility supporting a big range of array library versions is part of the mission. How big? Not sure, I think some rule of thumb like Ralf suggested sounds good.

Not sure we need testing for all the versions between the minimum and maximum version supported. Testing against the oldest version will keep array-api-compat "honest" - make sure nothing creeps in that doesn't work all the way back. Testing with the latest release to make sure things work with the newest version. And then as needed we can add an intermediate version if there is a particularly gnarly bug/transition/edge case.

[crusaderky]

I would definitely not throw cupy 13 users under the bus as soon as cupy 14 is released.
A 1-year support window sounds reasonable to me at this stage.
If we find out that a 1-year-old library breaks array-api-compat in a way that would require substantial work/mess to fix, we should discuss an exception for that specific library.

Not sure we need testing for all the versions between the minimum and maximum version supported.

I think lowest and latest is enough, plus numpy==2.0.0 due to its specific nuances.

[ev-br]

We discussed this in the Consortium meeting today (Dec 11, 2025). The summary is that

• known consumers (scipy, scikit-learn) do not really have a support policy for array libraries other than numpy;
• formulating a prescriptive policy feels premature just now, but will be needed when we graduate the support from experimental to mainline;
• meanwhile, a best-effort support for one-year old releases of cupy,torch and jax feels like a reasonable thing to keep.