Release Preparation

Prepare Release

Automate the Cherry Studio release workflow: collect changes → generate bilingual release notes → update files → create release branch → trigger CI/CD.

Arguments

Parse the version intent from the user's message. Accept any of these forms:

• Bump type keyword: patch, minor, major
• Exact version: strict x.y.z or x.y.z-<prerelease> without build metadata (e.g. 1.8.0, 1.8.0-beta.1, 1.8.0-rc.1)
• Natural language: "prepare a beta release", "bump to 1.8.0-rc.2", etc.

Defaults to patch if no version is specified. Always echo the resolved target version back to the user before proceeding with any file edits.

• --dry-run: Preview only, do not create a release branch.

Workflow

Step 1: Determine Version

1. For an interactive local run, fetch origin/main and all tags, then verify that the checkout is a clean main at exactly origin/main:

   git fetch origin refs/heads/main:refs/remotes/origin/main --tags
   test "$(git branch --show-current)" = main
   test -z "$(git status --porcelain)"
   test "$(git rev-parse HEAD)" = "$(git rev-parse origin/main)"

   Stop before editing files if any check fails. This prevents a standalone run from creating a release branch from an arbitrary or stale checkout. In GitHub Actions, use the workflow's frozen dispatch SHA and leave checkout validation to the workflow. Do not fetch or compare the later origin/main head.
2. Read the current version from package.json. Use it for version increments even if that release has since been withdrawn; never reuse the withdrawn version.
3. Select the latest published, non-draft GitHub Release whose tag is strict v<semver> as the release-note baseline. Non-semver preview releases and drafts are never a baseline:

   gh release list --limit 1000 --json isDraft,publishedAt,tagName --jq '[.[] | select(.isDraft == false and (.tagName | test("^v(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)(-[0-9A-Za-z-]+(\\.[0-9A-Za-z-]+)*)?$")))] | sort_by(.publishedAt) | last | .tagName // empty'

   Stop if no published baseline exists or its Git tag is missing (git rev-parse --verify refs/tags/{baseline-tag}). Compare its version with the current package version using semver: if main is behind, stop and require the latest Post Release metadata PR to be merged. If main is ahead, allow preparation using the published baseline for release notes and the package version for version increments. For example, after withdrawing 2.1.1, main at 2.1.1 with a published baseline of 2.1.0 prepares 2.1.2 and includes changes since 2.1.0. In GitHub Actions, use the workflow-provided baseline tag and collection base without repeating these checks.
4. Compute the new version based on the argument:
   • patch / minor / major: bump from the current version.
   • An exact version must match ^(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)(-[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*)?$ and pass semver.valid; build metadata such as +build.1 is not accepted.
   • In both cases, require the result to be strictly greater than the current version according to semver precedence. Reject equal versions and downgrades.

Step 2: Collect Commits

1. Determine the release-note collection base from the published baseline selected in Step 1, not from the package version:
   • If the baseline tag is an ancestor of HEAD, use the tag.
   • Otherwise, use the latest commit whose full message contains the exact marker release-metadata-boundary: <baseline-tag>. This machine marker is added to the Post Release pull request body and survives the required squash merge.
   • For metadata pull requests created before the machine marker existed, accept a subject exactly equal to chore(release): sync <baseline-tag> metadata or that subject followed only by GitHub's squash suffix (#<PR-number>).
   • Stop with an error if the tag is not an ancestor and its metadata sync commit is missing; otherwise already-released hotfixes could be included again.
2. List all commits since that base:

   git log <collection-base>..HEAD --format="%H %s" --no-merges

3. For each commit, get the full body:

   git log <hash> -1 --format="%B"

4. Extract the content inside ```release-note code blocks from each commit body.
5. Extract the conventional commit type from the title (feat, fix, refactor, perf, docs, etc.).
6. Skip these commits as standalone release-note candidates, but still inspect their effects when reconciling candidates with the final code in Step 3:
   • Titles starting with 🤖 Daily Auto I18N
   • Titles starting with Merge
   • Titles starting with chore(deps)
   • Titles starting with chore: release
   • Titles starting with chore(release)
   • Commits where the release-note block says NONE

Step 3: Generate Bilingual Release Notes

Generate release notes in both English and Chinese from the final user-visible changes relative to the published baseline. Commit titles and release-note blocks are candidate descriptions, not proof that a change will ship.

Reconcile net changes before drafting:

1. Inspect git diff --name-status <baseline-tag> <release-head>, then read the relevant patches and code at both endpoints. <release-head> is the source HEAD before release preparation (the frozen dispatch SHA in CI). Compare the two endpoint trees, not a three-dot merge-base diff. The collection base is only for discovering commits; when it differs from the published tag, also inspect user-visible differences missing from that commit range.
2. Group candidates by user-visible behavior and trace related patches in chronological order, including commits excluded in Step 2. Detect explicit reverts, manual undoing, replacements, partial reversals, and reintroductions from the code; do not rely on commit wording or matching hashes alone.
3. Omit a change introduced and fully undone during this cycle, including fixes that only addressed that temporary change. For partial reversals, replacements, or reintroductions, describe only the final outcome that differs from the published baseline, once per distinct user-visible change.
4. If a reversal removes or changes behavior that already existed in the published baseline, describe the resulting user-visible removal or restoration. Do not discard all revert commits indiscriminately. An implementation rewrite that preserves the same user-visible behavior does not by itself justify a release-note entry.
5. Verify each proposed item against the endpoint diff and final code, and ensure the English and Chinese versions describe the same outcome. If the claimed effect cannot be substantiated, omit it and report the uncertainty in the preparation summary rather than inventing a release-note claim.

Recommended format:

<!--LANG:en-->
Cherry Studio {version} - {Brief English Title}

✨ New Features
- [Component] Description

🐛 Bug Fixes
- [Component] Description

💄 Improvements
- [Component] Description

⚡ Performance
- [Component] Description

<!--LANG:zh-CN-->
Cherry Studio {version} - {简短中文标题}

✨ 新功能
- [组件] 描述

🐛 问题修复
- [组件] 描述

💄 改进
- [组件] 描述

⚡ 性能优化
- [组件] 描述
<!--LANG:END-->

The language markers are the machine-readable contract: include each marker once, keep them in order, and provide non-empty English and Chinese sections. Titles and surrounding explanatory text are presentation choices, not validation requirements.

Rules:

• Only include categories that have entries (omit empty categories).
• Each distinct surviving user-visible change appears once in the appropriate category; combine related commits and omit canceled or superseded claims.
• Prefer wording from the release-note field, or otherwise the commit title, only when it matches the verified final outcome.
• Component tags should be short: [Chat], [Models], [Agent], [MCP], [Settings], [Data], [Build], etc.
• Chinese translations should be natural, not machine-literal.
• Do NOT include commit hashes or PR numbers.
• Read the existing release notes in electron-builder.yml as a style reference before writing.

IMPORTANT: User-Focused Content Only

Release notes are for end users, not developers. Exclude anything users don't care about:

• EXCLUDE internal refactoring, code cleanup, or architecture changes
• EXCLUDE CI/CD, build tooling, or test infrastructure changes
• EXCLUDE dependency updates (unless they add user-visible features)
• EXCLUDE documentation updates
• EXCLUDE developer experience improvements
• EXCLUDE technical debt fixes with no user-visible impact
• EXCLUDE overly technical descriptions (e.g., "fix race condition in Redux middleware")

INCLUDE only changes that users will notice:

• New features they can use
• Bug fixes that affected their workflow
• UI/UX improvements they can see
• Performance improvements they can feel
• Security fixes (simplified, without implementation details)

Keep descriptions simple and non-technical:

• ❌ "Fix streaming race condition causing partial tool response status in Redux state"
• ✅ "Fix tool status not stopping when aborting"
• ❌ "Auto-convert reasoning_effort to reasoningEffort for OpenAI-compatible providers"
• ✅ "Fix deep thinking mode not working with some providers"