[rwgk]

codex on behalf of Ralf:

Summary

Make the two bindings source roots explicit without changing the distribution name or Python namespace. Both build cuda-bindings / cuda.bindings, in separate environments.

• Record exactly one current and one maintenance bindings root, their toolkit pins, and the shared Python matrix in ci/versions.yml. Currently these are CUDA 13.4 and CUDA 12.9; this is a two-line policy, not support for arbitrary numbers of release lines.
• Use standard setuptools-scm parsing with one tag selector per release line. The standalone metapackage carries its selectors in cuda_python/pyproject.toml; the metadata hook checks them against the bindings roots and registry.
• Preserve ordinary source installs: cuda-python defaults to CUDA 13; CUDA_PYTHON_BUILD_MAJOR=12 selects CUDA 12. Dependencies follow the resolved package version, so a CUDA 12 sdist rebuilt outside Git keeps CUDA 12 dependencies without requiring that variable. The CUDA 12 metapackage directly requires the matching bindings; CUDA 13 additionally declares Core and Pathfinder dependencies.
• Require Python 3.11 or newer consistently, including CUDA 12 metadata and current support documentation. Add a CUDA 12 Pixi workspace and lockfile alongside the existing per-package environments.
• Keep the checks that catch disagreement between packaging, toolkit pins, Pixi, and Core floors. Toolkit versions use structured numeric data internally. The registry metadata hook checks toolkit pins against Core floors; the separate Core hook checks its extras and documentation.
• Update contributor and agent guidance for two maintained roots. CUDA 12 gets its package-specific generation/build instructions in this layer. Implementation and review must inspect the counterpart root in either direction, then apply matching changes or explain why they do not apply.
• Retain backport_branch temporarily for existing release and backport consumers. Toolkit selection comes exclusively from the package-root registry; cuda.bindings: document shared maintenance and release branches #3178 removes the transitional field with its last consumer.
• Give CUDA 12 the external build dependency group and shared contribution-guide pointer already present for CUDA 13, while retaining CUDA 12-specific build inputs.

Toolkit pins select build inputs and the release family; setuptools-scm derives the package version from Git history. A package release patch version need not equal its toolkit patch pin.

The repository-only CI helper package shares parsing and declares its dependencies. It is not shipped in a CUDA Python runtime wheel. The temporary maintenance-version bootstrap is introduced with its actual CI callers in #3175.

CUDA 12 wheels deliberately adopt the existing CUDA 13 payload policy: omit .pyx implementation sources and .in generation templates while retaining Cython declarations/includes and required package headers. Source distributions retain the build inputs. The upcoming maintenance notes record this packaging change and the Python 3.11 minimum; Python 3.14/3.15 support was already released.

The SCM lifecycle instructions also define globally coordinated preview targets, including releases on branches whose tags main cannot reach, and require a matching milestone when changing a minor-line selector. A retained maintenance milestone and removal of the temporary bridge follow validated integration on main; this stack does not create or push that tag.

Stack / Review Boundary

Current main already contains cuda_bindings_12/ and cuda_bindings_13/. This remaining stack makes both roots participate in packaging, CI, documentation, and independent releases from the same integration branch, replacing routine CUDA 12 artifact sourcing from 12.9.x. Each root still builds the same cuda-bindings distribution and cuda.bindings namespace; use separate environments for the two majors.

The six open review layers are:

PR	Scope
#3174	Package configuration, version selection, developer environments, and cross-major review guidance
#3175	Change planning, wheel/sdist builds, and artifact reuse
#3176	GPU/source tests, coverage, documentation, and CI workflow integration
#3177	Releases selected from tagged source and exact-tag CI artifacts
#3178	Maintenance/release-branch policy and manual backport automation
#3182	Three CUDA 12 runtime helper fixes, with their regression coverage

#3174 through #3176 are intended to land together. They remain separate review scopes; #3174 and #3175 are incomplete CI states. Evaluate the combined integration at #3176. The remaining three PRs are subsequent layers, with the complete proposed source tree at #3182.

The stack baseline is main 03b4153574b3. The first two source-import/integration PRs are already merged into that baseline.

For the complete workflow, start with CONTRIBUTING.md, ci/README.md, .github/RELEASE-bindings.md, and the root/package AGENTS.md files in the top source tree. These documents are part of this stack and should describe the resulting development and release procedures.

Suggested Review Order

1. ci/versions.yml - the two package roots and shared Python matrix.
2. ci/tools/bindings_config.py - registry reading and cross-file consistency checks.
3. cuda_python/pyproject.toml and setup.py - standalone selectors, default selection, and version-derived dependencies.
4. CONTRIBUTING.md, root AGENTS.md, and CUDA 12 AGENTS.md - source builds, SCM milestones, generation rules, and bidirectional review.
5. CUDA 12 packaging and upcoming notes - Python support and the intentional wheel/sdist payload distinction.

Counterpart Review

Inspected both bindings roots' pyproject.toml, README, generation instructions, and shared build-helper layout, together with cuda_python/setup.py, Core's bindings floors, and the shared test bootstrap. Both READMEs now use --group test. CUDA 12 keeps its header parser, templates, legacy APIs, and redirector; CUDA 13 keeps its different generated layout. Those intentional differences are documented rather than copied across mechanically.

For this refresh, compared cuda_bindings_12/pyproject.toml with cuda_bindings_13/pyproject.toml, and CUDA 12's docs/source/contribute.md and CUDA 13's docs/source/contribute.rst with the shared CONTRIBUTING.md. CUDA 12 now exposes its own external-tools build group, including its retained pyclibrary input; CUDA 13 still installs local Pathfinder separately. Both contribution pages point to the shared guide.

Validation

Current local checks pass in full Git checkouts: 333 CI-tool tests at #3176, 346 at #3182, and 15 focused packaging tests. Full pre-commit run --all-files passes at both refreshed heads, including actionlint and Lychee. The tooling suite includes Git-based Pixi workspace discovery; it is not an archive-only suite. The local CUDA 13.4 TestVenv build and full QA run passed, covering Pathfinder, CUDA 13 bindings, PTDS, Cython interoperability, and Core. CUDA 12 native coverage is provided by the hosted matrix.

The focused packaging tests and earlier standalone sdist-to-wheel rehearsals cover default CUDA 13 selection, explicit CUDA 12 selection, and a CUDA 12 sdist rebuilt outside Git without a selector. That rebuild preserves CUDA 12 dependencies.

Before this security refresh, an independent audit of the candidate Linux CPython 3.12 CUDA 12 wheel retained all 38 historical declaration/include filenames, with all 34 internal dependency edges resolving. Its wheel omits implementation sources/templates; an sdist-only build retains all 76 tracked Cython/template inputs and packaging helpers. This historical archive audit was not repeated at the refreshed heads and does not establish every external use of implementation sources.

Current hosted CI for the #3174-#3176 integration: run, attempt 1, at 34664b270a324b5fa7d401d52c964ecf7ea1b84a - passed, 105/105 jobs. This is the cumulative integration boundary for native builds, GPU tests, source/sdist checks, and documentation.

#3174 is a packaging/configuration review boundary, not an independently migrated CI state.

Historical hosted artifact-reuse evidence (before this security refresh). Two temporary draft PRs exercised the production resolver unchanged against successful frozen baseline run 40426114619, at feb25b1b3d3c1744b680bf54ff10986ed4e59953. Both actual workplans matched the expected selective plans; neither fell back to a full rebuild. These runs predate the current interpreter/CA and driver-checksum integration; they establish the earlier reuse behavior, not validation of the refreshed heads or suitable nightly override IDs.

• CUDA 12 source-change case, #3237: run 40456909677 rebuilt CUDA 12 bindings/metapackage wheels while reusing Core, Pathfinder, and CUDA 13 wheels. All 28 build jobs passed, including bindings and Core Cython test-extension builds on Linux x86-64, Linux ARM64, and Windows. A re-uploaded Linux CPython 3.12 Core wheel is byte-identical to its baseline wheel. All 20 selected GPU tests (13 Linux and 7 Windows) and the final aggregate passed on the first attempt. That historical run completed successfully; no fixes or retries were needed.
• Linux test-workflow case, #3238: run 40460578171 skipped every package-wheel build, downloaded and re-uploaded the baseline packages, and successfully built all selected Cython test extensions and Core test binaries. All 45 expected reused package artifacts were present in that rehearsal run. All 42 selected GPU tests (24 x86-64 plus 18 ARM64 Linux rows, covering both CUDA majors) and the final aggregate passed on the first attempt. The seven planned Windows, sdist, and Core API skips were accepted.

Both historical workflows passed on their first attempts, including documentation/link checks and their final aggregates. No fixes or retries were needed. These probes cover the two scenarios above; no separate Core-only or metapackage-only hosted probe is claimed.

Checklist

• Focused tests protect selection, packaging, and release outcomes that could fail silently.
• This description identifies the layer's scope and validation boundary.

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[rwgk]

@mdboom, below is a codex assessment, based on a static code analysis, of which PRs in the stack might be independently mergable.

I'm not sure we should invest time into building temporary compatibility bridges. Would it work for you to aim for merging 3174, 3175, 3176 as one group? The idea would be to get them reviewed in this stack, but then combine the final reviewed code into one normal PR, to be merged as one unit (so that we don't have non-CI-testable intermediate states on main).

---

#3174 is not independently mergeable as written, but making it so is practical. Two changes currently require later layers:

• The new registry removes configuration fields that existing CI, documentation, release, and backport workflows still read. For example, the existing CI setup rejects the missing toolkit values.
• The metapackage now requires CUDA_PYTHON_BUILD_MAJOR, but its existing build callers do not supply it.

These layers were originally and intentionally divided for review; they do not all represent working intermediate states.

Current Boundaries

Cumulative stack through	Assessment
#3174	Existing CI breaks on the configuration and packaging changes.
#3175	Build integration arrives, but matching test-workflow changes are still missing.
#3176	First sensible full-CI target for both majors. Release and backport workflows still need later changes.
#3177	Release routing is updated; the old backport workflow remains incompatible.
#3178	First existing boundary that also completes those operational workflow updates.

These are code-based assessments; I have not run new CI.

Recommendation

Make #3174 independently mergeable with a small temporary compatibility bridge:

1. Retain the old configuration fields alongside the new registry, validating that their values agree.
2. Explicitly select CUDA 13 in the existing metapackage build callers.
3. Remove the transitional fields as later layers migrate their consumers.

That means several files and focused regression checks, without redesigning the stack or pulling substantial CI/release work into #3174.

This would let us merge the packaging foundation separately while keeping main operational. #3176 would then be the next useful cumulative full-CI target. Making #3175 independently functional would require substantially more boundary reshuffling, so I would defer that decision.

[rwgk]

I'll work ahead a bit, to see where we land:

codex response to my previous comment:

Yes—reviewing the three layers separately, then landing their combined result in one normal PR, looks practical. I read your comment; that approach avoids putting the incomplete intermediate states on main.

At the combined #3176 state, the toolkit configuration consumers and metapackage build callers have already been migrated. The remaining adjustment is considerably smaller than making #3174 independently mergeable.

Required Adjustment

Postpone removing backport_branch: "12.9.x" until #3178 retires its consumers.

That means:

• Retain the existing field in ci/versions.yml.
• Explicitly accept it in the otherwise strict registry validator, checking agreement with the maintenance line.
• Remove it in cuda.bindings: document shared maintenance and release branches #3178, together with the old backport workflow.

This preserves the existing backport workflow and current-major release-note checking. Both still require that setting; the release-note checker currently errors without it.

There is no need to restore the old toolkit configuration fields or add temporary metapackage defaults: the combined three-layer state already handles those.

Release Boundary

The intended intermediate state would be:

• Both majors build and test from main.
• Normal CUDA 13 releases remain supported. Tag-triggered CI builds only the matching major, so the existing release downloaders remain usable. Tag selection.
• CUDA 12 releases from main arrive with Release: select bindings artifacts from tagged package configuration #3177. Until then, CUDA 12 releases continue using compatible tooling on 12.9.x.

One existing policy change also needs explicit documentation: #3176’s release documentation resolver requires a registry in the tagged source. Dry-runs against older tags therefore require historical tooling. That policy is already intended for the finished stack; it takes effect here.

Keep Review Straightforward

I would organize the work as follows:

1. Add one focused commit to cuda.bindings: configure independent CUDA 12 and CUDA 13 packages #3174 preserving the still-used backport setting, with its validator checks.
2. Adjust cuda.bindings: document shared maintenance and release branches #3178 to remove it when the final consumer disappears.
3. Describe cuda.bindings: configure independent CUDA 12 and CUDA 13 packages #3174–CI: test and document both bindings majors on main #3176 as one merge group, with the release boundary stated clearly.
4. After review, create the combined PR and verify that its Git tree exactly matches the reviewed cumulative state.

Validation should include focused release/backport checks, plus one full CI run on the combined landing PR, rather than full runs on all three review layers.

This keeps the substantial review boundaries intact: packaging, builds, then tests/documentation. The additional change is a small correction to migration order. Nothing changed or triggered yet.

[rwgk]

@mdboom, #3174–#3176 now form a validated landing point, with separate review scopes for package configuration, builds, and tests/docs.

Full CI is green at both the cumulative #3176 head and the stack top, #3182. The #3176 state preserves the existing CUDA 13 release and backport flows; the later release-routing and maintenance-policy changes remain separate.

Could you please review #3174–#3176 with a view to landing them together? The intent is to retain the three review scopes, then combine them for merging (as explained in my previous comment).

[mdboom]

Found with my agent:

The 12.9.x branch builds cp310 wheels. Its build-wheel.yml matrix starts at 3.10, and I checked that on upstream/12.9.x. The shared python.supported list in [ci/versions.yml](vscode-webview://1lq1g48ng0sclg835m7ufv5pq987ujci9cjh6dj4ho9llgobp0ub/ci/versions.yml) starts at 3.11, and #3175 feeds it to every wheel build. After this stack, 12.9.x wheels for 3.10 stop being built. Meanwhile cuda_bindings_12 declares requires-python = ">=3.10", keeps the 3.10 classifier, and its pixi build variants include 3.10. Python 3.10 users would silently fall back to the old 12.9.10 or a source build. The change also drops the 3.9 classifier, and the 12.9.x pyproject has no requires-python. If dropping 3.10 is intended, raise requires-python to match. Otherwise the registry needs a per-package Python list.

I think maybe the bring-over of 12.9.x predates dropping of Python 3.10 support there. It is fine to drop Python 3.10 support across the board (even for 12.9.x cuda-bindings) since it is no longer supported. Let's just make all the updates necessary here to be consistent about that.