Upgrade the cuda-core version to ~1.1.0

[mdboom]

Updates the cuda-core dependency in cuda-python. This should have been done when cuda-core was last released, so added to the release instructions.

[rwgk]

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]

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.

[rwgk]

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.

I see, thanks!

[github-actions]

Doc Preview CI
Preview removed because the pull request was closed or merged.