From 9b4f4f4fa42ca133f216378cb1ac8f3d9961e464 Mon Sep 17 00:00:00 2001 From: DIYgod Date: Fri, 13 Feb 2026 10:50:01 +0800 Subject: [PATCH] feat: add desktop-release skill for regular version releases (#4834) * feat: add desktop-release skill for regular version releases Add a comprehensive skill for performing regular desktop releases from dev branch. Includes changelog management, mainHash evaluation (critical for determining whether users need full app updates vs lightweight renderer hot updates), and automated PR creation. The skill guides users through: 1. Gathering commits since last release and categorizing changes 2. Updating changelog with proper formatting 3. Evaluating whether mainHash should be updated (main process code changes) 4. Executing version bump with optional mainHash skip for faster renderer-only updates 5. Verifying PR creation Co-Authored-By: Claude Haiku 4.5 * fix: avoid unstaged bump.config.ts edit breaking git rebase Change the "skip mainHash" strategy from pre-editing bump.config.ts (which breaks `git pull --rebase` in the leading step) to a post-bump approach: let bump run normally, then restore the old mainHash value and amend + force push the release branch. Co-Authored-By: Claude Opus 4.6 * fix: correct working directory for mainHash restore step After `cd apps/desktop && pnpm bump`, the cwd is apps/desktop/. Add explicit `cd ../..` before the amend step so paths resolve correctly. Co-Authored-By: Claude Opus 4.6 --------- Co-authored-by: Claude Haiku 4.5 --- .claude/skills/desktop-release/SKILL.md | 145 ++++++++++++++++++++++++ 1 file changed, 145 insertions(+) create mode 100644 .claude/skills/desktop-release/SKILL.md diff --git a/.claude/skills/desktop-release/SKILL.md b/.claude/skills/desktop-release/SKILL.md new file mode 100644 index 000000000..4c657ebf8 --- /dev/null +++ b/.claude/skills/desktop-release/SKILL.md @@ -0,0 +1,145 @@ +--- +name: desktop-release +description: Perform a regular desktop release from the dev branch. Gathers commits since last release, updates changelog, evaluates mainHash changes, bumps version, and creates release PR. +disable-model-invocation: true +allowed-tools: Bash, Read, Write, Edit, Glob, Grep +--- + +# Desktop Regular Release + +Perform a regular desktop release. This skill handles the full release workflow from the `dev` branch. + +## Pre-flight checks + +1. Confirm the current branch is `dev`. If not, abort with a warning. +2. Run `git pull --rebase` in the repo root to ensure the local branch is up to date. +3. Read `apps/desktop/package.json` to get the current `version` and `mainHash`. + +## Step 1: Gather changes since last release + +1. Find the last release tag: + ```bash + git tag --sort=-creatordate | grep '^desktop/v' | head -1 + ``` +2. Get all commits since that tag on the current branch: + ```bash + git log ..HEAD --oneline --no-merges + ``` +3. Categorize commits into: + - **Shiny new things** (feat: commits, new features) + - **Improvements** (refactor:, perf:, chore: improvements, dependency updates) + - **No longer broken** (fix: commits, bug fixes) + - **Thanks** (identify external contributor GitHub usernames from commits) + +## Step 2: Update changelog + +1. Read `apps/desktop/changelog/next.md`. +2. Present the categorized changes to the user and draft the changelog content. +3. Wait for user confirmation or edits before writing. +4. Write the final content to `apps/desktop/changelog/next.md`, following the template format: + + ```markdown + # What's new in vNEXT_VERSION + + ## Shiny new things + + - description of new feature + + ## Improvements + + - description of improvement + + ## No longer broken + + - description of fix + + ## Thanks + + Special thanks to volunteer contributors @username for their valuable contributions + ``` + +5. Keep `NEXT_VERSION` as the placeholder - it will be replaced by `apply-changelog.ts` during bump. + +## Step 3: Evaluate mainHash + +This is critical for determining whether users need a full app update or can use the lightweight renderer hot update. + +1. Check what files changed in `apps/desktop/layer/main/` since the last release tag: + ```bash + git diff ..HEAD --name-only -- apps/desktop/layer/main/ + ``` +2. Also check changes to `apps/desktop/package.json` fields other than version/mainHash (since package.json is included in the hash calculation): + ```bash + git diff ..HEAD -- apps/desktop/package.json + ``` + +**Decision logic:** + +- If there are **NO changes** in `layer/main/` and no meaningful `package.json` changes (only version/mainHash/changelog-related), then mainHash should NOT be updated. Users will get a fast renderer-only hot update. +- If there are **trivial changes** in `layer/main/` (typo fixes, comment changes, logging tweaks) that don't affect runtime behavior, recommend NOT updating mainHash. Present the changes to the user and ask for confirmation. +- If there are **meaningful changes** in `layer/main/` (new features, bug fixes, dependency changes, API changes), mainHash MUST be updated. Users will need a full app update. + +Present your analysis to the user with: + +- List of changed files in `layer/main/` +- A summary of what changed +- Your recommendation (update or skip mainHash) +- Ask for explicit confirmation + +## Step 4: Save old mainHash and execute bump + +1. Save the current mainHash from `apps/desktop/package.json` for later comparison. +2. Change directory to `apps/desktop/` and run the bump: + ```bash + cd apps/desktop && pnpm bump + ``` +3. This command will: + - Pull latest changes + - Apply changelog (rename next.md to {version}.md, create new next.md) + - Recalculate mainHash and write to package.json + - Format package.json + - Bump minor version + - Commit with message `release(desktop): release v{NEW_VERSION}` + - Create branch `release/desktop/{NEW_VERSION}` + - Push branch and create PR to `main` + +## Step 5: Restore mainHash if skipping update + +If Step 3 decided mainHash should NOT be updated, restore the old value now. The bump has already committed, pushed, and created the PR on a new release branch, so we amend the commit and force push. This is safe because the release branch was just created. + +1. Change back to the repo root first (Step 4 left the working directory at `apps/desktop/`): + ```bash + cd ../.. + ``` +2. Ensure you are on the `release/desktop/{NEW_VERSION}` branch (bump should have switched to it). +3. Replace the recalculated mainHash with the saved old value in `apps/desktop/package.json`. +4. Stage and amend the release commit: + ```bash + git add apps/desktop/package.json && git commit --amend --no-edit + ``` +5. Force push the release branch: + ```bash + git push --force origin release/desktop/{NEW_VERSION} + ``` + +If Step 3 decided mainHash SHOULD be updated, skip this step entirely — the bump already wrote the correct new value. + +## Step 6: Verify + +1. Confirm the PR was created successfully by checking the output. +2. Report the new version number and PR URL to the user. +3. Summarize: + - New version: v{NEW_VERSION} + - mainHash updated: yes/no (and why) + - Changelog highlights + - PR URL + +## Reference + +- Bump config: `apps/desktop/bump.config.ts` +- Changelog dir: `apps/desktop/changelog/` +- Changelog template: `apps/desktop/changelog/next.template.md` +- mainHash generator: `apps/desktop/plugins/vite/generate-main-hash.ts` +- Hot updater logic: `apps/desktop/layer/main/src/updater/hot-updater.ts` +- CI build workflow: `.github/workflows/build-desktop.yml` +- Tag workflow: `.github/workflows/tag.yml`