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.core follows 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).

CUDA Version Support Matrix#

cuda.core version

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 oldest cuda-bindings release that meets two conditions. It was generated from the cuda.h major.minor that the published cuda-core wheels are built against. It provides every cuda-bindings API and fix that cuda-core needs. 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-bindings floors#

cuda-core version

CUDA 12

CUDA 13

1.3.1.dev8

cuda-bindings >= 12.9.8

cuda-bindings >= 13.5.0

  • At run time, import cuda.core requires an installed cuda-bindings that meets three conditions. It has the same major as the cuda-core build in use and is at least as new as that build’s floor. It was generated from a cuda.h at 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 older cuda-bindings fails at import with a message that names the version found, the version required, and the pip command that fixes it. cuda.core supports a newer cuda-bindings of the same major.

  • At build time, a source build requires cuda-bindings at or above the floor. It also requires a cuda.h, located through CUDA_PATH or CUDA_HOME, of the same major.minor as the header that cuda-bindings was generated from. Any other configuration fails the build with a message that names what was found and what is required. cuda.core does 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-core build works with every driver of its CUDA major. An older driver can lack some of the build’s features. In that case cuda-core never crashes or returns a wrong result; depending on the feature, it may raise an error or emulate the feature.

A floor moves only for one of two reasons. A cuda-core release needs a newer cuda-bindings API or fix, or its wheels are built against a newer CUDA minor version. A new cuda-bindings release alone does not move a floor, and a cuda-core release alone does not. The release notes list every move.

Python Version Support#

cuda.core supports all Python versions following the CPython EOL schedule. As of writing, Python 3.11 – 3.15 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.