release-notes
Use when cutting a CaskHub release, adding a CHANGELOG.md entry, or drafting the GitHub release body / Sparkle appcast description
来源信息
- 仓库
- alielsokary/CaskHub
- 最近来源活动
- 2026年7月20日 23:32
- 检测到的 SKILL.md 语言
- 英语
- 星标
- 1,264
- 分支
- 53
安装方式
默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。
检查来源文件
决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。
正在显示 SKILL.md
SKILL.md
来源说明 · 只读预览- name
- release-notes
- description
- Use when cutting a CaskHub release, adding a CHANGELOG.md entry, or drafting the GitHub release body / Sparkle appcast description
# CaskHub Release Notes
## Overview
`CHANGELOG.md` at the repo root (Keep a Changelog style: cumulative, newest
first) is the single source. `Scripts/release.sh` extracts the TOP entry and
uses it as both the GitHub release body and the Sparkle update dialog notes
(embedded into `appcast.xml`, rendered as markdown). Feature-PR descriptions are
not covered by this standard — keep them as detailed as you like. The release PR
is the exception (see Release PR description below).
## Format
Each release adds one entry at the top of `CHANGELOG.md`:
```markdown
## x.y.z — YYYY-MM-DD
### What's New
- Bullet per user-visible feature
### Improvements
- Bullet per enhancement to something that already existed
### Bug Fixes
- Bullet per user-visible fix
```
- The top `##` header MUST be the version being cut — `release.sh` aborts on
mismatch, so forgetting to add the new entry fails loudly.
- Omit any section that would be empty. A patch release may be Bug Fixes only.
- Never rewrite past entries; only add the new one on top.
## Writing the bullets
Source material: `git log --oneline --first-parent <prev-tag>..HEAD` and the
merged PR titles/descriptions since the last release.
- User-facing language: say what changed for the user, not how it was built
("Faster search results", not "Refactored CaskRepository query path").
- Start each bullet with a verb (Added / Fixed / Improved…), sentence case,
no trailing period, one line each.
- Collapse related minor fixes into one bullet; aim for ≤6 bullets a section.
- Never include: back-merge PRs ("master to develop"), version-bump/appcast
commits ("release: x.y.z"), CI/workflow changes, test-only changes, refactors
or dependency bumps with no user-visible effect, PR numbers, commit hashes.
- If literally everything in the range is internal, write one honest bullet
under Improvements ("Under-the-hood stability improvements") rather than
padding.
## Release PR description
The `release/x.y.z → master` PR body is two parts, in order, and nothing else:
1. **Changelog** — the version's What's New / Improvements / Bug Fixes bullets
(the same content that ships as the release notes).
2. **Release artifacts** — a short list of what the build produced: the
notarized zip and build number, the appcast update, the README bump, dSYMs.
Merging behavior lives in the runbook and the publish-release.yml /
sync-develop.yml workflows, not in the PR body.
## Example entry
```markdown
## 0.7.0 — 2026-08-02
### What's New
- Added import and export for your installed app list
### Improvements
- Faster cask search while typing
### Bug Fixes
- Fixed Homebrew repair getting stuck after relaunch
- Fixed update badge showing for already-updated casks
```
在 GitHub 查看