.clinerules/workflows/hotfix-release.md
Create a hotfix release by cherry-picking specific commits from main onto the latest release tag.
This workflow helps you:
First, ensure we're on main and up to date:
git checkout main && git pull origin main
Get the latest release tag:
git tag --sort=-v:refname | head -1
Show all commits on main since the last release tag:
LAST_TAG=$(git tag --sort=-v:refname | head -1)
git log ${LAST_TAG}..HEAD --oneline --format="%h %s (%an)"
Also get the commit messages already on the tag (to identify previously cherry-picked commits). Note: Run these as separate commands to avoid shell parsing issues with parentheses in author names:
LAST_TAG=$(git tag --sort=-v:refname | head -1)
PREV_TAG=$(git tag --sort=-v:refname | head -2 | tail -1)
git log $PREV_TAG..$LAST_TAG --oneline --format="%s"
Present the list to the user in a numbered format with commit hash, subject, and author. For any commits whose subject line already appears in the tag's history (previously cherry-picked in an earlier hotfix) or are "Release Notes" commits, add (already in previous hotfix) or (release notes - skip) after them so the user knows to skip those.
Ask which commits to include in the hotfix.
Use the ask_followup_question tool to let the user specify which commits they want (by number or hash).
For each selected commit:
git show --no-patch --format="%B" <hash>git show <hash> --statgh pr list --search "<hash>" --state merged --json number,title --jq '.[0]'Build a mental model of what these changes do for the changelog.
Parse the current version from package.json and the last tag:
LAST_TAG=$(git tag --sort=-v:refname | head -1)
echo "Last release: $LAST_TAG"
cat package.json | grep '"version"'
Hotfixes always increment the patch version (e.g., 3.40.0 -> 3.40.1, or 3.40.1 -> 3.40.2).
Ask the user to confirm the new version number.
On the main branch, create a commit that updates:
CHANGELOG.md - Add a new section for the hotfix version at the top:
## [3.40.1]
- Description of fix 1
- Description of fix 2
Write clear, user-friendly descriptions based on your analysis of the commits.
package.json - Update the version field to the new version
No changelog-entry file cleanup is needed. Contributors do not create changelog-entry files in this repo.
Skip running npm run install:all - release automation handles lockfile consistency as needed.
Commit with message format: v{VERSION} Release Notes (hotfix)
In the commit body, mention:
git add CHANGELOG.md package.json
git commit -m "v3.40.1 Release Notes (hotfix)
Hotfix release including:
- <commit1-hash>: <description>
- <commit2-hash>: <description>
"
Push to main:
git push origin main
Checkout the last release tag (detached HEAD):
LAST_TAG=$(git tag --sort=-v:refname | head -1)
git checkout $LAST_TAG
Cherry-pick the selected commits in order:
git cherry-pick <commit1-hash>
git cherry-pick <commit2-hash>
# ... etc
Finally, cherry-pick the release notes commit you just pushed to main:
# Get the hash of the release notes commit (should be HEAD of main)
RELEASE_NOTES_COMMIT=$(git rev-parse main)
git cherry-pick $RELEASE_NOTES_COMMIT
After all cherry-picks are applied successfully:
# Tag the new release
git tag v{VERSION}
# Push the tag to remote
git push origin v{VERSION}
Return to main branch:
git checkout main
Copy a Slack announcement message to clipboard with the version and PR links for each included fix:
VS Code Hotfix v{VERSION} Published
- Description of fix 1 https://github.com/cline/cline/pull/{PR_NUMBER}
- Description of fix 2 https://github.com/cline/cline/pull/{PR_NUMBER}
Present a final summary:
Remind the user to:
v{VERSION} as the tag)