Skip to content

Upgrade the cuda-core version to ~1.1.0 #2716

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
mdboom merged 2 commits into from
Aug 28, 2026
Merged

Upgrade the cuda-core version to ~1.1.0 #2716

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f989e7d
Upgrade the cuda-core version to 1.1.1
mdboom Aug 27, 2026
d229e80
Merge branch 'main' into update-cuda-core-version-1.1.1
mdboom Aug 27, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions .github/RELEASE-core.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -64,6 +64,8 @@ platforms as appropriate for each release.
Review `cuda_core/pyproject.toml` and verify that all dependency
requirements are current.

Update the cuda_core dependency in `cuda_python/setup.py`.

---

## Sweep deprecations whose removal version has arrived
Expand Down
2 changes: 1 addition & 1 deletion cuda_python/setup.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@
version=version,
install_requires=[
f"cuda-bindings{matcher}{version}",
"cuda-core~=1.0.0",
"cuda-core~=1.1.0",

@rwgk rwgk Aug 27, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cuda-core~=1.1.0 means the effective range is >=1.1.0,<1.2.0. Do we want it this restrictive?

WDYT about specifying cuda-core~=1.1 instead, with effective range >=1.1,<2.0?

PEP 440 explicitly makes the number of version segments significant. CUDA Core promises backward-compatible minor releases and breaking changes only at major boundaries in cuda_core/docs/source/support.rst. It even already has 1.2.0 notes deferring an API removal until 2.0 for precisely that reason: cuda_core/docs/source/release/1.2.0-notes.rst.

Concrete outcomes:

  • Core 1.1.1: both specifications accept it.
  • Core 1.2.0: ~=1.1.0 rejects it, potentially causing another downgrade or conflict; ~=1.1 accepts it.
  • Core 2.0.0: ~=1.1 still rejects it, matching the documented breaking-change boundary.
  • nccl4py's ~=1.0 combined with PR 2716's ~=1.1.0 intersects only at 1.1.x. Combined with ~=1.1, it permits every compatible release from 1.1 through the rest of 1.x.

There is a separate lower-bound question. The PR branch and commit say "1.1.1", and cuda_core/docs/source/release/1.1.1-notes.rst says that release fixes compatibility with cuda-bindings 13.4.0b1. If 1.1.1 is genuinely required, the best constraint is:

cuda-core>=1.1.1,<2

Otherwise, cuda-core~=1.1 seems like the right expression.

If you choose another expression, could you please add a comment with a terse rationale? (~=1.1 is sufficiently intuitive and doesn't really need a comment.)

@mdboom mdboom Aug 27, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cuda-core~=1.1.0 means the effective range is >=1.1.0,<1.2.0. Do we want it this restrictive?

I personally don't want to be this restrictive. This is just a conservative change that will allow newer cuda-core to install when we make the next cuda-python release without changing the status quo. And we /need/ to change something now because as it stands we are preventing the installation of the latest cuda-core.

PEP 440 explicitly makes the number of version segments significant. CUDA Core promises backward-compatible minor releases and breaking changes only at major boundaries in cuda_core/docs/source/support.rst. It even already has 1.2.0 notes deferring an API removal until 2.0 for precisely that reason: cuda_core/docs/source/release/1.2.0-notes.rst.

Yes, but that is about API compatibility, not behavior. There is still the opportunity for runtime breakage because the versions of cuda-bindings and cuda-core have never been tested together.

The idea here (as told to me be @leofang) is that cuda-python should be a convenient way to get cuda-bindings and cuda-core that has been tested together. If we loosen the upper bound on cuda-core, that means some future version of cuda-core that was never tested could be installed.

Personally, I think we can and should broaden it further, but that requires stepping back and making sure our CI continues to cover the new cases and combinations that would create. I would like to get this conservative "broken in the same way as the status quo" change out now in advance of the next cuda-python release.

"cuda-pathfinder~=1.1",
],
extras_require={
Expand Down
Loading