[rwgk]

codex on behalf of Ralf:

Summary

Release one bindings line and its matching metapackage using the package layout and toolkit settings in ci/versions.yml at the release tag. A release tag may be on main or a stabilization branch containing the new configuration.

• Keep workflow-control tools separate from tagged package sources. A newer workflow revision must use the tagged source's layout, versions, and wheel matrix.
• Require a successful push CI run for the exact tag and source SHA, either discovered automatically or checked against the supplied run ID.
• Select the requested component/toolkit artifacts and validate wheel filenames for distribution, version, ABI/platform, and complete expected coverage. This is not an inspection of wheel payload provenance.
• Release the selected bindings and metapackage without building/releasing the other bindings major, Core, or Pathfinder. Use published dependencies where appropriate.
• Preserve component-specific upload, documentation, verification, and GitHub Release behavior, including Pathfinder's final automatic publication after both-index verification.
• Run release resolution, note checks, validation, and publishing helpers with hardened Python from the workflow control checkout. Tagged package data stays separate; no-checkout Pathfinder verification keeps its isolated hardened environment.

Tagged Configuration and Compatibility

For example, a future v12.9.11 tag whose registry records cuda_bindings_12 with toolkit 12.9.1 selects that root and toolkit while releasing package version 12.9.11. The package and toolkit patch versions need not match. The registry at that tag is used even if the workflow-control revision records different pins.

The current release workflow requires a schema-2 ci/versions.yml in the tagged source for every component, including Core and Pathfinder, for both dry-runs and publication. Pre-registry tags require layout-compatible historical tooling whose control branch has the applicable current CI security fixes. Existing published packages and immutable tags are unchanged.

Release Notes and Publication

Normal bindings, metapackage, and Core releases require their own exact-version, nonempty .rst notes in the tagged component source. Their .postN releases remain exempt. Pathfinder requires a notes file for every release, including .postN, but permits it to be empty. Another component's notes or the workflow-control tree cannot fill a missing tagged-source file.

Bindings/metapackage releases prepare a shared GitHub Release draft for the owner to review and publish after both component releases. The final bindings release guide is added in #3178.

Stack / Review Boundary

Previous: #3176. Next: #3178. The stack overview lists all six open PRs and the intended workflow.

#3174 through #3176 are intended to land together, with separate review scopes and cumulative CI at #3176; the first two are incomplete intermediate states. Release routing (#3177), maintenance policy (#3178), and the runtime fixes (#3182) follow that group. The complete proposed source tree is at #3182.

Baseline: main 03b4153574b3.

Suggested Review Order

1. .github/workflows/release.yml
2. ci/tools/lookup-run-id
3. ci/tools/validate_release_wheels.py
4. ci/tools/check_release_notes.py
5. .github/RELEASE-core.md

Counterpart Review

Inspected both tagged bindings records, metapackage selectors, component-specific release-note policies, and release documentation/artifact consumers. Source-root selection remains data-driven for both majors; the workflow-control checkout does not substitute its own package configuration or notes for the tagged source.

For this refresh, checked .github/workflows/release.yml and release-upload.yml together: every Python helper uses the workflow-owned interpreter while release-source/ci/versions.yml, tagged package metadata, and notes remain inputs. Both no-checkout Pathfinder verification jobs retain the workflow-owned action and their separate verification venv.

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.

Release-tool regressions cover tagged-source selection, exact run/tag matching, artifact routing, wheel-matrix completeness, and component-specific notes policies.

Current hosted CI for the complete stack: run, attempt 3, at 341d286d865b012976898347c6728fda1e6c6a98 - passed, 105/105 jobs. This covers the cumulative stack and its runtime backports, rather than hosted release publication or backport execution.

One existing Windows Python 3.14t/Core row needed two failed-job retries: first for an access violation in incremental linking, then for a different graph-lifetime failure. Both cases passed on the final attempt and also passed at #3176; the affected Core sources are unchanged from main. No tests were skipped, serialized, or weakened for these retries. The graph failure remains a separate Core investigation; the passing retry does not establish that the suspected registry race is fixed.

No hosted release dry-run, package upload, GitHub Release publication, or retained milestone creation was performed. Ordinary PR CI and the local tests do not exercise the release workflow end-to-end. For pre-registry tags, the documented historical ref-selection recipe is conditional on first applying current security fixes to the compatible control branch; an old source layout alone is not sufficient.

Checklist

• Relevant existing and focused regression tests cover the integration behavior.
• 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.