Generate (and optionally open) a PyTorch release tracker / cherry-pick tracking issue from a release announcement, like https://github.com/pytorch/pytorch/issues/180506. Triggered by mentions of "release tracker", "release tracking issue", "cherry-pick tracker", or "cut a release branch issue".
Generate (and optionally open) a PyTorch release tracker / cherry-pick tracking issue from a release announcement, like https://github.com/pytorch/pytorch/issues/180506. Triggered by mentions of "release tracker", "release tracking issue", "cherry-pick tracker", or "cut a release branch issue".
Create Release Tracker Issue
Generates the body for a PyTorch release tracker issue (the cherry-pick tracking issue cut alongside a release branch, like https://github.com/pytorch/pytorch/issues/180506) from a release announcement that contains the milestone (key dates) schedule, then opens the issue in pytorch/pytorch.
When to use this skill
Use when the user asks to:
Create a release tracker / release tracking issue for a PyTorch release
Create the cherry-pick tracking issue for a newly cut release branch
Turn a "PyTorch release X.Y key dates" announcement into a tracker issue
Instructions
Step 1: Determine parameters
Collect these parameters. Most can be derived; ask only for what is missing.
If given pasted text, parse the dates directly from it.
Map the announcement milestones to the tracker fields. Keep the date format exactly as written in the announcement (e.g. DD/MM/YY, and keep a week of prefix if present):
Tracker field
Source milestone
M3_DATE
M3 — Release branch cut
M4_DATE
M4 — Release branch finalized / feature classifications published
M4_1_DATE
M4.1 — Tutorial drafts submission deadline
M5_DATE
M5 — External-Facing Content Finalized
M6_DATE
M6 — Release Day
PHASE_CUTOFF
The M4 date. If M4 is written as week of 22/6/26, use the bare date 22/6/26 for the phase cutoff.
If a milestone is missing from the announcement, ask the user rather than guessing.
Step 3: Generate the issue body
Fill the template below. Replace every {PLACEHOLDER}:
We cut a [release branch](https://github.com/pytorch/pytorch/tree/release/{BRANCH}) for the {VERSION} release.
Our plan from this point is roughly:
* Phase 1 (until {PHASE_CUTOFF}): work on finalizing the release branch
* Phase 2 (after {PHASE_CUTOFF}): perform extended integration/stability/performance testing based on Release Candidate builds.
This issue is for tracking cherry-picks to the release branch.
## Release dates* M3: Release branch cut ({M3_DATE})
* M4: Release branch finalized, Announce final launch date, Feature classifications published ({M4_DATE}) - Final RC is produced.
* M4.1: Tutorial drafts submission deadline ({M4_1_DATE})
* M5: External-Facing Content Finalized ({M5_DATE})
* M6: Release Day ({M6_DATE})
## Cherry-Pick Criteria**Phase 1 (until {PHASE_CUTOFF}):**
Only low-risk changes may be cherry-picked from main:
1. Fixes to regressions against the most recent minor release (e.g. {PREV_MINOR}.x for this release; see [module: regression issue list](https://github.com/pytorch/pytorch/issues?q=is%3Aissue+is%3Aopen+label%3A%22module%3A+regression%22+))
2. Critical fixes for: [silent correctness](https://github.com/pytorch/pytorch/issues?q=is%3Aissue+is%3Aopen+label%3A%22topic%3A+correctness+%28silent%29%22), [backwards compatibility](https://github.com/pytorch/pytorch/issues?q=is%3Aissue+is%3Aopen+label%3A%22topic%3A+bc-breaking%22+), [crashes](https://github.com/pytorch/pytorch/issues?q=is%3Aissue+is%3Aopen+label%3A%22topic%3A+crash%22+), [deadlocks](https://github.com/pytorch/pytorch/issues?q=is%3Aissue+is%3Aopen+label%3A%22topic%3A+deadlock%22+), (large) [memory leaks](https://github.com/pytorch/pytorch/issues?q=is%3Aissue+is%3Aopen+label%3A%22topic%3A+memory+usage%22+)
3. Critical fixes to new features introduced in the most recent minor release (e.g. {PREV_MINOR}.x for this release)
4. Test/CI fixes
5. Documentation improvements
6. Compilation fixes or ifdefs required for different versions of the compilers or third-party libraries
7. Release branch specific changes (e.g. change version identifiers)
Any other change requires special dispensation from the release managers (currently {RELEASE_MANAGERS} ). If this applies to your change please write "Special Dispensation" in the "Criteria Category:" template below and explain.
**Phase 2 (after {PHASE_CUTOFF}):**
Note that changes here require us to rebuild a Release Candidate and restart extended testing (likely delaying the release). Therefore, the only accepted changes are **Release-blocking** critical fixes for: [silent correctness](https://github.com/pytorch/pytorch/issues?q=is%3Aissue+is%3Aopen+label%3A%22topic%3A+correctness+%28silent%29%22), [backwards compatibility](https://github.com/pytorch/pytorch/issues?q=is%3Aissue+is%3Aopen+label%3A%22topic%3A+bc-breaking%22+), [crashes](https://github.com/pytorch/pytorch/issues?q=is%3Aissue+is%3Aopen+label%3A%22topic%3A+crash%22+), [deadlocks](https://github.com/pytorch/pytorch/issues?q=is%3Aissue+is%3Aopen+label%3A%22topic%3A+deadlock%22+), (large) [memory leaks](https://github.com/pytorch/pytorch/issues?q=is%3Aissue+is%3Aopen+label%3A%22topic%3A+memory+usage%22+)
Changes will likely require a discussion with the larger release team over VC or Slack.
## Cherry-Pick Process
1. Ensure your PR has landed in master. This does not apply for release-branch specific changes (see Phase 1 criteria).
2. Create (but do not land) a PR against the [release branch](https://github.com/pytorch/pytorch/tree/release/{BRANCH}).
<details>
```bash
# Find the hash of the commit you want to cherry pick
# (for example, abcdef12345)
git log
git fetch origin release/{BRANCH}
git checkout release/{BRANCH}
git cherry-pick -x abcdef12345
# Submit a PR based against 'release/{BRANCH}' either:
# via the GitHub UI
git push my-fork
# via the GitHub CLI
gh pr create --base release/{BRANCH}
```
You can also use the `@pytorchbot cherry-pick` command to cherry-pick your PR. To do this, just add a comment in your merged PR. For example:
```
@pytorchbot cherry-pick --onto release/{BRANCH} -c docs
```
(`-c docs` - is the category of your changes - adjust accordingly):
For more information, see [pytorchbot cherry-pick docs](https://github.com/pytorch/pytorch/wiki/Bot-commands#cherry-pick).
</details>
3. Make a request below with the following format:
```
Link to landed trunk PR (if applicable):
*
Link to release branch PR:
*
Criteria Category:
*
```
1. Someone from the release team will reply with approved / denied or ask for more information.
2. If approved, someone from the release team will merge your PR once the tests pass.
Please note HUD Link with branch CI status and link to the HUD to be provided here.
[]()
cc @seemethere @malfet @pytorch/pytorch-dev-infra
### Versions
{VERSION}
Step 4: Review, then create the issue
Show the rendered body to the user for confirmation. Creating a GitHub issue is an outward-facing action — do not create it until the user approves the content (or has clearly asked you to open it directly).
Create the issue in pytorch/pytorch with the exact title and labels:
Title:[v.{VERSION}] Release Tracker (note the v. prefix — e.g. [v.2.13.0] Release Tracker)
If gh is unavailable, POST to https://api.github.com/repos/pytorch/pytorch/issues with {"title": ..., "labels": ["release tracker", "triaged"], "body": ...} using an authenticated token.
Report the new issue URL back to the user.
Example usage
Example — Create the 2.13.0 tracker from the key-dates announcement:
Create a release tracker issue for 2.13.0 from https://dev-discuss.pytorch.org/t/pytorch-release-2-13-key-dates/3390
For that announcement the milestones resolve to:
Field
Value
M3 (branch cut)
week of 8/6/26
M4 (finalized)
week of 22/6/26
M4.1 (tutorial drafts)
30/6/26
M5 (content finalized)
1/7/26
M6 (release day)
8/7/26
Phase cutoff
22/6/26
Previous minor
2.12
Producing title [v.2.13.0] Release Tracker with labels release tracker, triaged.
Notes
Phase cutoff = the M4 date. Both the "Phase 1 (until …)" / "Phase 2 (after …)" lines and the "Phase 1/2" cherry-pick criteria headers use the bare M4 date (strip a week of prefix for the cutoff, even though the M4 line in the Release dates section keeps it).
Preserve the announcement's date format verbatim (DD/MM/YY). Do not reformat or convert dates.
The release tracker label must already exist in the repo (it does in pytorch/pytorch). If creating in a repo without it, create the label first or drop it.
Keep the trailing cc @seemethere @malfet @pytorch/pytorch-dev-infra line unless the user specifies different reviewers.
The release managers handles default to @atalman, @malfet; update only if the user names different managers.
**Do not land the release branch PR yourself.**
**NOTE: Our normal tools (ghstack / ghimport, etc.) do not work on the release branch.**
