Address review feedback on RELEASE.md

- Remove internal nvbug link, keep example text
- Condense dependency check guidance
- Remove stale note about docs build failing on tag push
- Clarify test verification uses checked-out repo
- Document three conda-forge approaches (bot auto, bot request, manual)

Co-authored-by: Cursor <cursoragent@cursor.com>

Author: Andy-Jost

.github/ISSUE_TEMPLATE/release_checklist.yml

@@ -10,7 +10,7 @@ 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.md](../RELEASE.md) for detailed guidance on each step.
+        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).
 
   - type: checkboxes
     id: subpackage-tasks

.github/RELEASE.md .github/RELEASE-core.md.github/RELEASE.md renamed to .github/RELEASE-core.md

@@ -1,9 +1,15 @@
 <!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. -->
 <!-- SPDX-License-Identifier: Apache-2.0 -->
 
-# Release Process
+# cuda.core Release Process
 
-This document provides detailed guidance for each step of the
+This document covers the `cuda.core` release process. For other packages:
+`cuda-bindings` and `cuda-python` involve a private repository and are not
+documented here; `cuda-pathfinder` is largely automated by the
+[release-cuda-pathfinder.yml](workflows/release-cuda-pathfinder.yml)
+workflow.
+
+Each section below provides detailed guidance for a step in the
 [Release Checklist](ISSUE_TEMPLATE/release_checklist.yml). To start a
 release, create a new issue from that template and work through it item by
 item, referring back here as needed.
@@ -12,12 +18,12 @@ item, referring back here as needed.
 
 ## File an internal nvbug
 
-Create an nvbug from the SWQA template to request pre-release validation.
-To find the template, search for a previous release's nvbug (e.g. by
-title "Release of cuda.core") and create a new bug from the same template.
+Create an nvbug to request that SWQA begin post-release validation.  Issues
+identified by that process are typically addressed in a patch release.  To find
+the template, search for a previous release's nvbug (e.g. by title "Release of
+cuda.core") and create a new bug from the same template.
 
-Example (from the cuda.core v0.6.0 release,
-[nvbug 5910741](https://nvbugspro.nvidia.com/bug/5910741)):
+Example:
 
 > **Title:** Release of cuda.core v0.6.0
 >
@@ -48,28 +54,15 @@ Example (from the cuda.core v0.6.0 release,
 > - PyPI wheel upload
 > - Post-release validation
 
-**How to determine the SW combinations:**
-
-- **cuda.core version**: The version being released.
-- **cuda.bindings, CTK, and CUDA driver versions**: Check with the release owner.
-
-Update the version, SW combinations, and platforms as appropriate for each
-release.
+Update the version, SW combinations (check with the release owner), and
+platforms as appropriate for each release.
 
 ---
 
 ## Check (or update if needed) the dependency requirements
 
-Review `cuda_core/pyproject.toml` and verify the following are current:
-
-- `requires-python` — supported Python version range
-- `dependencies` — runtime dependencies (e.g. `numpy`)
-- `[project.optional-dependencies]` — `cuda-bindings` version pins for
-  `cu12` / `cu13` extras
-- `[build-system] requires` — Cython and setuptools version pins
-- `[dependency-groups]` — test dependencies (`ml-dtypes`, `cupy`,
-  `cuda-toolkit` version pins)
-- Python version classifiers in `[project]`
+Review `cuda_core/pyproject.toml` and verify that all dependency
+requirements are current.
 
 ---
 
@@ -120,8 +113,6 @@ git push origin cuda-core-v0.6.0
 Pushing the tag triggers a CI run automatically. Monitor it in the
 **Actions** tab on GitHub.
 
-- **The docs build is expected to fail** on tag-triggered runs. This is
-  normal — docs are built during the release workflow instead.
 - **All CI tests should succeed.** If any fail, investigate and rerun as
   needed.
 - Note the **run ID** of the successful tag-triggered run. The release
@@ -149,10 +140,10 @@ publish to PyPI.
      [`ci/versions.yml`](../ci/versions.yml) (e.g. `13.1.1`)
    - **Which wheel index to publish to**: `testpypi`
 
-2. Wait for the workflow to complete. The docs build step will fail on
-   forks — this is expected and does not block the wheel upload.
+2. Wait for the workflow to complete.
 
-3. Verify the TestPyPI upload by installing and running tests locally:
+3. Verify the TestPyPI upload by installing and running tests from a
+   checked-out copy of the repository:
 
    ```bash
    pip install -i https://test.pypi.org/simple/ \
@@ -177,27 +168,43 @@ pip install cuda-core==0.6.0
 ## Update the conda recipe & release conda packages
 
 The conda-forge feedstock builds from the GitHub Release source archive
-(not from PyPI). The bot (`regro-cf-autotick-bot`) does not always pick up
-new releases automatically, so you may need to open the PR manually.
+(not from PyPI). There are three approaches to updating the feedstock,
+from least effort to most control.
 
-### Fork and clone the feedstock
+### Approach A: Wait for the bot
 
-```bash
-gh repo fork conda-forge/cuda-core-feedstock --clone
-cd cuda-core-feedstock
-```
+The `regro-cf-autotick-bot` periodically scans for new releases and opens
+a PR automatically. If nothing has changed in the build requirements, the
+bot's PR may be sufficient — review it and ask a feedstock maintainer
+to merge. However, the bot only
+updates the version and sha256. If build dependencies, import paths, or
+other recipe fields have changed, the bot's PR will be incomplete and CI
+will fail.
+
+### Approach B: Request a bot update
+
+If the bot hasn't opened a PR, you can request one explicitly. Go to the
+feedstock's Issues tab and create a new "Bot commands" issue:
+
+- **Title**: `@conda-forge-admin, please update version`
+- **Body**: (leave empty)
 
-Optional: Set up remotes so your fork is named after your GitHub username:
+This triggers the bot to create a version-bump PR. As with approach A,
+review the PR and push additional fixes if needed.
+
+### Approach C: Manual PR
+
+For full control — or when the bot's PR needs extensive fixes — open a
+PR manually from a fork.
+
+**Fork and clone** (one-time setup):
 
 ```bash
-git remote rename origin <your-github-username>
-git remote add origin https://github.com/conda-forge/cuda-core-feedstock.git
-git fetch origin
+gh repo fork conda-forge/cuda-core-feedstock --clone
+cd cuda-core-feedstock
 ```
 
-### Update `recipe/meta.yaml`
-
-Create a branch and edit `recipe/meta.yaml`:
+**Create a branch and edit `recipe/meta.yaml`:**
 
 ```bash
 git checkout -b update-v0.6.0 origin/main
@@ -215,16 +222,16 @@ Update the following fields:
        | sha256sum
    ```
 
-4. **Host dependencies**: Ensure all headers needed at build time are
-   listed. For example, v0.6.0 added a Cython C++ dependency on
-   `nvrtc.h`, requiring `cuda-nvrtc-dev` to be added to both `host`
-   requirements and `ignore_run_exports_from`.
+4. **Host dependencies**: Ensure all build-time dependencies are listed.
+   For example, v0.6.0 added a Cython C++ dependency on `nvrtc.h`,
+   requiring `cuda-nvrtc-dev` in both `host` requirements and
+   `ignore_run_exports_from`.
 
 5. **Test commands and descriptions**: Update any import paths or
    descriptions that changed (e.g. `cuda.core.experimental` ->
    `cuda.core`).
 
-### Open a PR
+**Open a PR:**
 
 ```bash
 git add recipe/meta.yaml
@@ -238,9 +245,12 @@ gh pr create \
     --body "Update cuda-core to version 0.6.0."
 ```
 
+### Notes
+
 The feedstock CI (Azure Pipelines) triggers automatically on the PR.
-Monitor it for build failures — common issues include missing
-build-time header dependencies (see host dependencies above).
+Monitor it for build failures — common issues include missing build-time
+header dependencies. Feedstock maintainers (listed in
+`recipe/meta.yaml` under `extra.recipe-maintainers`) can merge the PR.
 
 ---
 
@@ -252,13 +262,22 @@ build-time header dependencies (see host dependencies above).
 
 ## Finalize the announcement update
 
-*TBD*
+The release workflow creates a draft GitHub Release. To publish it:
+
+1. Go to the repository on GitHub, click **Tags**, then switch to the
+   **Releases** tab.
+2. Find the draft release for the new tag and click **Edit**.
+3. Copy the body from a previous release as a starting point. It
+   typically links to the release notes in the documentation (e.g.
+   `https://nvidia.github.io/cuda-python/cuda-core/latest/release/0.6.0-notes.html`).
+4. Update the link and any version references, then click
+   **Publish release**.
 
 ---
 
 ## Send out the announcement internally
 
-*TBD*
+The release owner will prepare and send the announcement.
 
 ---