cuda.bindings: support multiple CTK release lines on main

.github/ISSUE_TEMPLATE/release_checklist.yml

@@ -10,25 +10,26 @@ body:
   - type: markdown
     attributes:
       value: |
-        This checklist is for cuda-core releases as well as cuda-bindings patches. Please go through this checklist and ensure all tasks are completed. See [RELEASE-core.md](../RELEASE-core.md) for detailed guidance on each step (cuda.core).
+        This checklist is for cuda-core releases as well as cuda-bindings patches. See [RELEASE-core.md](../RELEASE-core.md) for cuda.core and [RELEASE-bindings.md](../RELEASE-bindings.md) for bindings release scope, stabilization branches, and validation.
 
   - type: checkboxes
     id: subpackage-tasks
     attributes:
       label: Tasks for cuda-core and cuda-bindings patch release
       options:
         - label: File an internal nvbug to communicate test plan & release schedule with QA
-        - label: Ensure all pending PRs are reviewed, tested, and merged
+        - label: Record the release scope and ensure all PRs selected for this release are reviewed, tested, and merged
         - label: Check (or update if needed) the dependency requirements
         - label: Sweep deprecations whose stated removal version has arrived (`grep -rn 'deprecated::' cuda_core/cuda`) and remove any that are due
         - label: "Finalize the doc update, including release notes (\"Note: Touching docstrings/type annotations in code is OK during code freeze, apply your best judgement!\")"
         - label: Update the docs for the new version
-        - label: Create a public release tag
-        - label: Wait for the tag-triggered CI run to complete, and use that run ID for release workflows (this will upload the release to PyPI)
+        - label: Record the exact source commit, workflow control revision, and selected package root before creating the approved public release tag
+        - label: Wait for the exact tag-triggered CI run to pass and complete a release dry run before approving publication
         - label: Publish the release at https://github.com/NVIDIA/cuda-python/releases (this will trigger the conda package update)
         - label: Approve the conda-package update PR
         - label: Post-release QA
         - label: Finalize the announcement update
         - label: Send out the announcement internally (on `#swcuda-python`)
         - label: Send out the announcement externally (GitHub Release -> Announcement)
-        - label: For a `cuda-bindings` release, make sure MAJOR and MAJOR-1 releases are made, as well as releases of `cuda-python` for MAJOR and MAJOR-1
+        - label: For a `cuda-bindings` release, confirm which supported release lines are in scope using `ci/versions.yml`, and release the matching `cuda-python` package for each planned line
+        - label: For a bindings stabilization or emergency branch, link the PRs returning applicable fixes to `main` and record their applicability to both bindings roots

.github/RELEASE-bindings.md

@@ -0,0 +1,93 @@
+<!--
+SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+SPDX-License-Identifier: Apache-2.0
+-->
+
+# Releasing CUDA bindings
+
+## Choose the release scope and source
+
+Develop the current and maintenance CUDA major lines together on `main`, in
+the two package roots listed in [`ci/versions.yml`](../ci/versions.yml).
+Release each line independently. A bindings release also needs its matching
+`cuda-python` metapackage release; it does not require a release of the other
+CUDA major, `cuda-core`, or `cuda-pathfinder`.
+
+Major-line maintenance may include selected API, Python, platform, or other
+compatibility changes. Decide those changes explicitly and describe them in
+the release notes. Once a patch release is frozen, admit only its approved
+fixes and release prerequisites. Do not infer patch-release scope solely
+from the registry's `maintenance` role.
+
+For an ordinary release, select a tested commit on `main`. If stabilization
+must continue while development advances, create a short release branch such
+as `release/bindings-12.9.10` from the chosen commit. For an emergency after a
+release, start from its exact tag, provided that tag contains the new package
+layout. For the first release after this transition, use a validated commit
+containing both roots; do not resume development on the historical `12.9.x`
+branch. Keep the package layout and release tooling together on the branch.
+
+Record the source commit, intended tag, selected package root, release owner,
+and accepted changes in the release checklist. A branch is a temporary scope
+boundary, not a separate long-term home for shared infrastructure.
+
+## Move fixes between integration and release branches
+
+Prefer a reviewed fix on `main`, then backport it to the selected release
+branch. Run **CI: Backport a merged PR to a release branch** from the Actions
+tab on `main`, supplying the merged PR number and one existing target branch.
+The workflow opens a PR; it does not merge or release the result. Inspect the
+diff, request CI using the normal PR approval procedure, and review it before
+merging. Workflow-file changes require a manual backport with appropriate
+credentials. Conflicts and toolkit-specific generated changes require an
+explicitly reviewed adaptation.
+
+If urgency requires a fix on the release branch first, link a follow-up PR
+returning the fix to `main` before closing the release checklist. In either
+direction, assess both bindings roots and record why a change applies to one
+or both. Regenerate affected generated files from the intended toolkit and
+cybind inputs instead of blindly copying generated output between majors.
+See the [shared maintenance policy](../ci/README.md#maintaining-both-bindings-roots).
+
+## Validate and publish the selected line
+
+1. Finalize the bindings and metapackage release notes, dependency constraints,
+   and selected toolkit pin in the release source tree. The registry and
+   packaging metadata must agree. Run the CI-tool suite and pre-commit checks.
+2. Test the candidate through a reviewed PR or manual CI dispatch on its
+   branch. Normal development CI includes dependent packages and may cover
+   both majors. Resolve failures in affected code before selecting the tag.
+3. Create the approved immutable `vX.Y.Z` tag at the selected source commit.
+   The tag-triggered CI selects that line's bindings and metapackage, validates
+   them with the published Pathfinder dependency, and builds release artifacts.
+   The tag does not have to be on `main`. Wait for this exact tag's CI to pass.
+4. Run **CI: Release** with `release-action=dry-run`, the tag, and
+   `component=cuda-bindings`; repeat for `cuda-python`. Leave `run-id` blank
+   to exercise automatic lookup, and leave `dry-run-docs-branch` blank to avoid
+   deploying docs. The workflow verifies a successful tag-triggered CI run
+   with the exact source SHA, validates artifacts, and builds docs.
+5. Review the dry runs, then separately approve and run `full-release` for
+   each component under the team's release procedure. A successful candidate
+   rehearsal or ordinary branch CI is not a substitute for exact-tag CI.
+6. Finish post-release QA and announcements, return every applicable fix to
+   `main`, and close the stabilization effort. Retain immutable tags and the
+   branch history needed for diagnosis.
+
+The workflow revision used for a release is its **control revision**; the
+tagged commit is its **source revision**. Record both and the artifact CI run
+ID. Release routing uses the package layout and toolkit settings in
+`ci/versions.yml` at the release tag. The current tooling requires a valid
+schema-2 registry in that source, for both dry runs and publication, including
+Core and Pathfinder releases. Tags from before this registry was introduced
+require compatible historical tooling; the current workflow configuration
+cannot supply missing tagged configuration. Published releases remain unchanged.
+
+In **CI: Release**, normal releases require each component's exact-version,
+nonempty release notes in the tagged source. The `cuda-python` metapackage requires its own notes.
+Notes from the workflow control revision or a different component cannot fill
+a gap. Preserve the existing exemption for `.postN` releases, which do not
+require new notes.
+
+Local synthetic tags used in publication-incapable rehearsals must remain local;
+they do not authorize publishing a package, creating a remote tag, or moving
+an existing tag.

.github/actions/doc_preview/action.yml

@@ -20,7 +20,7 @@ runs:
   steps:
     - name: Deploy doc preview
       if: ${{ startsWith(github.ref_name, 'pull-request/') }}
-      uses: JamesIves/github-pages-deploy-action@d92aa235d04922e8f08b40ce78cc5442fcfbfa2f  # v4.8.0
+      uses: JamesIves/github-pages-deploy-action@fa24774553152dd7873cd16ebd8d959b010c5445  # v4.9.0
       with:
         git-config-name: cuda-python-bot
         git-config-email: cuda-python-bot@users.noreply.github.com

.github/dependabot.yml

@@ -47,23 +47,3 @@ updates:
         patterns: ["*"]
 
     labels: [CI/CD, dependencies]
-
-  # GitHub Actions updates targeting the 12.9.x branch
-  - package-ecosystem: github-actions
-    directory: /
-    target-branch: "12.9.x"  # keep in sync with backport_branch in ci/versions.yml
-    schedule:
-      interval: "monthly"
-      time: "09:00"
-      timezone: "America/Los_Angeles"
-
-    # Keep churn down: only one open PR from this ecosystem at a time
-    open-pull-requests-limit: 1
-
-    groups:
-      actions-monthly:
-        applies-to: version-updates
-        patterns: ["*"]
-        update-types: ["major", "minor", "patch"]
-
-    labels: [CI/CD, dependencies]

.github/labeler.yml

@@ -7,7 +7,9 @@
 
 cuda.bindings:
   - changed-files:
-    - any-glob-to-any-file: 'cuda_bindings/**'
+    - any-glob-to-any-file:
+      - 'cuda_bindings/**'
+      - 'cuda_bindings_*/**'
 
 cuda.core:
   - changed-files:

.github/workflows/backport.yml

@@ -2,75 +2,84 @@
 #
 # SPDX-License-Identifier: Apache-2.0
 
-name: "CI: Backport the merged PR"
+name: "CI: Backport a merged PR to a release branch"
 
 on:
-  pull_request_target:
-    types: [closed, labeled]
-    branches:
-      - main
   workflow_dispatch:
     inputs:
       backport-branch:
-        description: "Branch to backport commits onto"
-        required: false
+        description: "Existing release branch to receive the fix"
+        required: true
         type: string
       pull-request:
-        description: "PR to backport"
+        description: "Merged PR to backport"
         required: true
         type: number
 
-
 permissions:
-  contents: write       # so it can comment
-  pull-requests: write  # so it can create pull requests
+  contents: write
+  pull-requests: write
+
+concurrency:
+  group: backport-${{ inputs.pull-request }}-${{ inputs.backport-branch }}
+  cancel-in-progress: false
 
 jobs:
-  backport-from-pr:
-    name: Backport directly from a pull request
-    if: ${{ github.repository_owner == 'nvidia' &&
-            github.event.pull_request.merged == true &&
-            contains( github.event.pull_request.labels.*.name, 'to-be-backported')
-         }}
+  backport:
+    if: github.repository == 'NVIDIA/cuda-python'
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
+      - name: Checkout workflow source
+        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
+        with:
+          ref: ${{ github.sha }}
 
-      - name: Load branch name
-        id: get-branch
+      - name: Validate source PR and target branch
+        env:
+          GH_TOKEN: ${{ github.token }}
+          GH_REPO: ${{ github.repository }}
+          DEFAULT_BRANCH: ${{ github.event.repository.default_branch }}
+          BACKPORT_BRANCH: ${{ inputs.backport-branch }}
+          PR_NUMBER: ${{ inputs.pull-request }}
         run: |
-          OLD_BRANCH=$(yq '.backport_branch' ci/versions.yml)
-          echo "OLD_BRANCH=${OLD_BRANCH}" >> $GITHUB_ENV
+          set -euo pipefail
+          if [[ ! "$PR_NUMBER" =~ ^[1-9][0-9]*$ ]]; then
+            echo "::error::The source PR must be a positive integer."
+            exit 1
+          fi
+          if ! git check-ref-format "refs/heads/$BACKPORT_BRANCH"; then
+            echo "::error::Provide one exact target branch name."
+            exit 1
+          fi
+          if [[ "$BACKPORT_BRANCH" == "$DEFAULT_BRANCH" ]]; then
+            echo "::error::Choose a release branch, not the default branch."
+            exit 1
+          fi
+          if ! git ls-remote --exit-code --heads origin "refs/heads/$BACKPORT_BRANCH"; then
+            echo "::error::The target branch must already exist in this repository."
+            exit 1
+          fi
+          if [[ "$(gh pr view "$PR_NUMBER" --repo "$GH_REPO" --json state --jq .state)" != MERGED ]]; then
+            echo "::error::The source PR must already be merged in this repository."
+            exit 1
+          fi
 
-      - name: Create backport pull requests
+      # Workflow-file changes need a manual backport because GITHUB_TOKEN
+      # cannot push them. Generated changes need target-specific regeneration.
+      - name: Create backport pull request
+        id: backport
         uses: korthout/backport-action@8560fb503c275d433c56f05a2f64850093baa9f7  # v4.7.0
         with:
+          source_pr_number: ${{ inputs.pull-request }}
+          target_branches: ${{ inputs.backport-branch }}
+          # The explicit target must not be combined with source PR labels.
+          label_pattern: ''
           copy_assignees: true
-          copy_labels_pattern: true
+          copy_labels_pattern: '^(?!to-be-backported$|backport ).*'
           copy_requested_reviewers: true
-          target_branches: ${{ env.OLD_BRANCH }}
-  backport-to-branch:
-    name: Backport a specific PR against a specific branch
-    if: github.repository_owner == 'nvidia' && github.event_name == 'workflow_dispatch'
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
 
-      - name: Load branch from environment name
-        if: inputs.backport-branch == null
+      - name: Require successful backport
+        if: steps.backport.outputs.was_successful != 'true'
         run: |
-          BACKPORT_BRANCH=$(yq '.backport_branch' ci/versions.yml)
-          echo "BACKPORT_BRANCH=${BRANCH}" >> $GITHUB_ENV
-
-      - name: Load branch name from input
-        if: inputs.backport-branch != null
-        run: echo "BACKPORT_BRANCH=${{ inputs.backport-branch }}" >> $GITHUB_ENV
-
-      - name: Create backport pull requests
-        uses: korthout/backport-action@8560fb503c275d433c56f05a2f64850093baa9f7  # v4.7.0
-        with:
-          copy_assignees: true
-          copy_labels_pattern: true
-          copy_requested_reviewers: true
-          target_branches: ${{ env.BACKPORT_BRANCH }}
-          source_pr_number: ${{ inputs.pull-request }}
+          echo "::error::Backport failed; resolve the conflict or prepare the target-specific fix manually."
+          exit 1