[DOC]: CUDA Python 12.9.1 Release notes are incomplete

[lahwaacz]

Is this a duplicate?

• I confirmed there appear to be no duplicate issues for this bug and that I agree to the Code of Conduct

Is this for new documentation, or an update to existing docs?

Update

Describe the incorrect/future/missing documentation

The CUDA Python 12.9.1 Release notes is very incomplete:

Released on Aug 6, 2025.
Included components

• cuda.bindings 12.9.1

Highlights

• Add bindings for cuFile

Known issues

• Updating from older versions (v12.6.2.post1 and below) via pip install -U cuda-python might not work. Please do a clean re-installation by uninstalling pip uninstall -y cuda-python followed by installing pip install cuda-python.

But the diff between 12.9.0 and 12.9.1 looks more like major release rather than patch release: v12.9.0...v12.9.1

Also note that the text is identical to the CUDA Python 13.0.0 Release notes.

If this is a correction, please provide a link to the incorrect documentation. If this is a new documentation request, please link to where you have looked.

No response

[lahwaacz]

There is at least 1 new Python package that needs to be documented properly in the release notes: cuda.path_finder

[leofang]

Hi, thanks for reporting!

But the diff between 12.9.0 and 12.9.1 looks more like major release rather than patch release: v12.9.0...v12.9.1

Also note that the text is identical to the CUDA Python 13.0.0 Release notes.

These are expected because of the way this repository is set up to host multiple component packages. The diff is inevitably affected by other components that are considered irrelevant to the new tag (in this case, cuda.core).

As for the cuda-python release note, I have two comments:

1. As we move to make cuda-python a meta package, it is better that we do not copy/paste from each component's release note, but instead have clickable links to included components, which is why the release notes are more and more succinct as we make the transition. We want to avoid making mistakes in copy-pastas (which happened several times).
   1. From this perspective, cuda-python 12.9.1/13.0.0 release notes should look roughly identical.
2. The omission of cuda-pathfinder is arguably an issue:
   1. We currently do not have a documentation for cuda-pathfinder that's linkable yet (Add Sphinx docs for cuda.pathfinder #760, cc @rwgk for vis)
   2. cuda-pathfinder is considered a transitive dependency to cuda-python (from cuda-bindings), see here. Though it's probably a good idea to also include cuda-pathfinder in cuda-python[all]. I'll raise a PR.

[lahwaacz]

These are expected because of the way this repository is set up to host multiple component packages. The diff is inevitably affected by other components that are considered irrelevant to the new tag (in this case, cuda.core).

But the CUDA Python 12.9.1 Release notes have only one item in the "Included components" section: cuda.bindings. Why is cuda.core missing when it causes such a huge diff? There should be a link to cuda.core 0.3.1 Release Notes or cuda.core 0.3.2 Release Notes.

[leofang]

Because cuda-core is not yet part of cuda-python, see #148 and cuda-python's setup.py linked earlier.

[lahwaacz]

Well, that is wrong, because the release archives (any of the 3 assets) contain all components: cuda_bindings, cuda_core, cuda_pathfinder, and the meta-package cuda_python 🤷

[leofang]

Well, that is wrong, because the release archives (any of the 3 assets) contain all components

I am not sure if you follow or if I wasn't being clear, quoting my reply from earlier:

These are expected because of the way this repository is set up to host multiple component packages. The diff is inevitably affected by other components that are considered irrelevant to the new tag (in this case, cuda.core).

We don't control the release artifacts associated with a git tag, certainly not those attached under https://github.com/NVIDIA/cuda-python/tags, Git/GitHub do. A git tag is repository-wide instead of covering a subset of directories. Once we tag, GitHub automatically generates and attaches them (the zip and the tarball) to a release. We can't even delete them when editing the release notes.

We can certainly attach more artifacts to a release ourselves (today we use a custom workflow which explains the third asset that you saw). But as far as source code is concerned, we just repeat what GitHub does (uploading a snapshot of the repo associated with the tag), mainly to avoid GitHub's own artifacts getting regenerated and leading the file hash changed (there's a long history behind this need). We need a stable file hash for downstream to consume.