| name | hotfix-release |
|---|---|
| description | Publish a hotfix (patch) release for one or more packages from an existing release branch. Use when the user wants to kick, start, or perform a hotfix release on a release/* branch. |
Instructions for publishing a hotfix (patch) release for one or more packages from an existing release/* branch.
⚠️ Prerequisites: Arelease/<sprint-name>branch must already exist with the fix commit(s) merged into it. If it does not exist, create one from the last release tag commit first.
Before starting, confirm the following with the user:
- Release branch name: e.g.
release/february-2026 - Package(s) being hotfixed: one or more packages, e.g.
@azure-tools/typespec-client-generator-core(tcgc)@azure-tools/typespec-azure-core(azure-core)@azure-tools/typespec-autorest(autorest)
-
Fetch the release branch:
git fetch origin release/<sprint-name>
-
Verify the fix commit is present on the release branch:
git log origin/release/ -10 < sprint-name > --oneline
-
Create a new branch from the release branch. Use a name that reflects the package(s) being hotfixed:
git checkout -b publish/hotfix/<name>-<sprint-name> origin/release/<sprint-name>
Naming convention:
- Single package: use the package shortname, e.g.
publish/hotfix/tcgc-february-2026 - Multiple packages: use a descriptive group name, e.g.
publish/hotfix/tcgc-and-azure-core-february-2026 - All packages: use a general name, e.g.
publish/hotfix/all-february-2026
- Single package: use the package shortname, e.g.
-
Ensure the
coresubmodule is at the correct commit for this branch:git submodule update --init
3. Run the version bump command with --ignore-policies (required for hotfix releases since the release branch is not main):
pnpm chronus version --ignore-policies-
IMPORTANT: If the
coresubmodule pointer was changed by the version bump, reset it — the submodule should NOT change in a hotfix:git checkout -- core
-
Verify only the intended files are changed:
git diff --stat
You should see ONLY (repeated per hotfixed package):
- Deleted
.chronus/changes/<file>.md(one per fix) - Modified
packages/<package-name>/package.json - Modified
packages/<package-name>/CHANGELOG.md
- Deleted
⚠️ If any packages were bumped that are NOT in the hotfix target list, investigate before proceeding.
-
Commit the version bump:
git add -A git commit -m "Bump version for hotfix: <pkg1>@<version1>, <pkg2>@<version2>, ..."Examples:
- Single:
"Bump version for hotfix: tcgc@0.65.1" - Multiple:
"Bump version for hotfix: tcgc@0.65.1, azure-core@1.2.1"
- Single:
-
Push the branch:
git push origin publish/hotfix/<name>-<sprint-name>
- Open a PR from
publish/hotfix/<name>-<sprint-name>targetingrelease/<sprint-name>(NOTmain) - Wait for CI to pass
- Squash merge the PR
- The publish pipeline will automatically release the new package version(s) to NPM
After the hotfix PR is merged:
- A workflow should automatically create a backmerge branch named
backmerge/release/<sprint-name>-YYYY-MM-DD - Find the backmerge branch at https://github.com/Azure/typespec-azure/branches
- Open a PR from the backmerge branch targeting
main - Rebase merge the backmerge PR into
main
⚠️ The backmerge ensures the hotfix and version bump are reflected inmain. Do NOT skip this step.
⚠️ The PR MUST targetrelease/<sprint-name>, NOTmain⚠️ Always use--ignore-policieswithpnpm chronus versionon release branches⚠️ Always reset thecoresubmodule pointer if it was changed (git checkout -- core)⚠️ Only the targeted package(s) should have version changes — verify withgit diff --stat⚠️ Always complete the backmerge tomainafter the hotfix is published⚠️ If therelease/<sprint-name>branch does not exist yet, create it from the last release tag commit before starting