cuda.core Support Policy#
Versioning Scheme#
cuda.core follows Semantic Versioning (SemVer) with the version
format major.minor.patch:
Major: Bumped when a new CUDA major release is out and support for the oldest CUDA major version is dropped. Breaking API changes only happen at major-version boundaries.
Minor: Bumped when new, backward-compatible features are added, or when a new Python feature release is out and the oldest supported Python version reaches EOL.
Patch: Bumped for bug fixes and backward-compatible maintenance updates.
Unlike cuda.bindings, the cuda.core version is not aligned with the CUDA Toolkit version.
Consult the table below or the release notes to determine which CUDA versions are
supported by a given cuda.core release.
Project Lifecycle & Release Cadence#
cuda.corefollows its own release cadence, independent of CUDA Toolkit releases, as long as SemVer guarantees are maintained.We currently aim for bimonthly releases, though this is subject to change.
Major version releases are aligned to CUDA major version releases.
New features may be delivered in minor releases at any time — not gated by the CUDA Toolkit release schedule.
Patch releases can be made on an as-needed basis, subject to urgency and the team’s bandwidth.
We currently do not plan to maintain multiple releases, nor have any backport policy for new features or bug fixes.
Deprecation notices will be issued at least for one (1) minor release, before the actual removal happens.
CUDA Version Support#
cuda.core is actively maintained to support the two (2) most recent CUDA major versions. For
example, cuda.core 1.x supports CUDA 12 and 13.
In particular, what this entails is that all CUDA minor versions within the two major releases
(12.x, 13.x) are supported by the same cuda-core package at run time. Any CUDA driver and any
CUDA Toolkit libraries of a supported major work with the same cuda-core wheel. The exception
is cuda-bindings, which has a minimum version per release. See
cuda-bindings Version Requirements below.
When a new CUDA major version is released and support for the oldest major version is dropped,
cuda.core will release a new major version (e.g., 1.x → 2.0.0).
|
Supported CUDA versions |
|---|---|
1.x |
12, 13 |
As with any CUDA library, certain features may impose additional requirements on the minimum CUDA library or CUDA driver versions. Refer to the individual module documentation for details.
cuda-bindings Version Requirements#
For each supported CUDA major version, each cuda-core release declares a minimum
cuda-bindings version, its floor. The floor is the newest cuda-bindings release of that
major at the time of the cuda-core release. The published wheels are built against it. The
cu12 and cu13 extras of cuda-core in pyproject.toml declare the floors of the
current release. The build, the import-time check, this page, and CI all read them from there.
|
CUDA 12 |
CUDA 13 |
|---|---|---|
1.2.1.dev171 |
|
|
At run time,
import cuda.corerequires an installedcuda-bindingsthat meets three conditions. It has the same major as thecuda-corebuild in use and is at least as new as that build’s floor. It was generated from acuda.hat least as new, by major.minor, as the one the build compiled against. The published wheels are built against the floor’s header, so the floor alone satisfies them. An oldercuda-bindingsfails at import with a message that names the version found, the version required, and thepipcommand that fixes it.cuda.coresupports a newercuda-bindingsof the same major.At build time, a source build requires
cuda-bindingsat or above the floor. It also requires acuda.h, located throughCUDA_PATHorCUDA_HOME, of the same major.minor as the header thatcuda-bindingswas generated from. Any other configuration fails the build with a message that names what was found and what is required.cuda.coredoes not support a build against a CUDA Toolkit older than the floor’s minor.The CUDA driver. The floor does not change the driver requirement. A
cuda-corebuild works with every driver of its CUDA major. An older driver can lack some of the build’s features. In that casecuda-corenever crashes or returns a wrong result; depending on the feature, it may raise an error or emulate the feature.
A floor moves with each cuda-core release, to the newest cuda-bindings of each major at
that time. It also moves in any release whose changes need a newer cuda-bindings API. The
release notes list every move under “Breaking Changes”.
Python Version Support#
cuda.core supports all Python versions following the CPython EOL schedule. As of writing, Python 3.10 – 3.14 are supported.
When a new Python feature version is released and the oldest supported version reaches EOL,
cuda.core will bump its minor version accordingly.
Free-threading Build Support#
Starting cuda-core 0.4.0, packages for the free-threaded interpreter are shipped to PyPI and conda-forge.
This support is currently experimental.
For now, you are responsible for making sure that calls into the underlying CUDA libraries are thread-safe. This is subject to change.
The NVIDIA CUDA Python team reserves the right to amend the above support policy. Any major changes, however, will be announced to users in advance.