Skip to content

Commit 78c58f7

Browse files
Andy-Jostclaude
andcommitted
docs(release): tag cuda-core releases on a release branch
Add a "Create the release branch" step to RELEASE-core.md and the release checklist template. Each minor series gets one protected branch, release/cuda-core-vX.Y.x, cut from main after the pre-release PRs merge. Tags go on that branch, and patch releases land there by cherry-pick PRs. Co-Authored-By: Claude Opus 5.5 <[email protected]>
1 parent fe9bb74 commit 78c58f7

2 files changed

Lines changed: 32 additions & 4 deletions

File tree

‎.github/ISSUE_TEMPLATE/release_checklist.yml‎

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -23,7 +23,8 @@ body:
2323
- label: Sweep deprecations whose stated removal version has arrived (`grep -rn 'deprecated::' cuda_core/cuda`) and remove any that are due
2424
- label: "Finalize the doc update, including release notes (\"Note: Touching docstrings/type annotations in code is OK during code freeze, apply your best judgement!\")"
2525
- label: Update the docs for the new version
26-
- label: Create a public release tag
26+
- label: Create the release branch (`release/cuda-core-vX.Y.x`) from `main` for a minor release, or check out the existing one for a patch release
27+
- label: Create a public release tag on the release branch
2728
- 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)
2829
- label: Publish the release at https://github.com/NVIDIA/cuda-python/releases (this will trigger the conda package update)
2930
- label: Approve the conda-package update PR

‎.github/RELEASE-core.md‎

Lines changed: 30 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -142,17 +142,44 @@ built and deployed automatically by the release workflow.
142142

143143
---
144144

145+
## Create the release branch
146+
147+
Each `cuda-core` minor series has one release branch,
148+
`release/cuda-core-vX.Y.x`. Releases are tagged on that branch, not on
149+
`main`. Patch releases of the series land there too.
150+
151+
For a minor release (`X.Y.0`), create the branch after every pre-release
152+
pull request has merged into `main`. Branch from the `main` commit that
153+
holds the final release notes:
154+
155+
```bash
156+
git fetch origin main
157+
git push origin origin/main:refs/heads/release/cuda-core-v0.6.x
158+
```
159+
160+
For a patch release (`X.Y.Z`), use the existing branch. Changes reach it
161+
through pull requests that cherry-pick the fixes from `main`, with
162+
`(cherry picked from commit ...)` trailers. The release notes for the patch
163+
release also go to `main`, so the docs switcher and the `latest` docs list
164+
them.
165+
166+
The repository ruleset protects `release/**`: a push to an existing release
167+
branch needs a pull request and passing checks.
168+
169+
---
170+
145171
## Create a public release tag
146172

147173
**Warning:** Pushing a tag is a potentially irrevocable action. Be absolutely
148174
certain the tag points to the correct commit before pushing.
149175

150176
Tags should be GPG-signed. The tag name format is `cuda-core-v<VERSION>`
151-
(e.g. `cuda-core-v0.6.0`). The tag must point to a commit on `main`.
177+
(e.g. `cuda-core-v0.6.0`). The tag must point to a commit on the release
178+
branch.
152179

153180
```bash
154-
git checkout main
155-
git pull origin main
181+
git fetch origin release/cuda-core-v0.6.x
182+
git checkout --detach origin/release/cuda-core-v0.6.x
156183
git tag -s cuda-core-v0.6.0 -m "cuda-core v0.6.0"
157184
git push origin cuda-core-v0.6.0
158185
```

0 commit comments

Comments
 (0)