release

name	release
description	Release a new version of go-masker: update CHANGELOG.md from git log, create GitHub release. Use when the user says 「發布」「release」「發新版」「打 tag」「release new version」or similar. Also use when the user says 「更新 changelog」if they clearly intend to release afterward.

Release

Publish a new go-masker version.

Module 結構

master branch 是 v3，v2 維護在 release/v2 branch。

master (default)
├── go.mod        ← module github.com/ggwhite/go-masker/v3
└── masker.go     ← v3 code

release/v2 (maintenance)
├── go.mod        ← module github.com/ggwhite/go-masker/v2
└── masker.go     ← v2 code

Module	Branch	Tag 格式	範例
v3	master	vX.Y.Z	v3.0.0
v2	release/v2	vX.Y.Z	v2.4.3

Workflow

0. Determine which module to release

Ask the user if not clear: "要發 v2 還是 v3？"

• v3: work on master branch
• v2: work on release/v2 branch

1. Determine version

git tag -l 'v${MAJOR}.*' --sort=-v:refname | head -1

Bump the patch number by default. If the user specifies minor or major, bump accordingly.

Version rules (from CLAUDE.md):

• patch x.y.Z: bug fix, docs, internal changes that don't affect API
• minor x.Y.0: new feature, new masker type, backwards-compatible API addition
• major X.0.0: breaking changes (removed API, changed behavior, module path change)

Show the user: "上個版本是 vX.Y.Z，這次準備發 vA.B.C" and confirm before continuing.

2. Collect changes

git log <last-tag>..HEAD --oneline --no-decorate

If there are zero relevant commits since the last tag, stop and tell the user there's nothing to release.

3. Draft changelog section

Read the existing CHANGELOG.md to match its style. The format follows Keep a Changelog:

## [X.Y.Z] - YYYY-MM-DD

### Features

- **Short name** — description of the feature

### Fixes

- **Short name** — description of the fix

Categorization rules:

• fix / bugfix commits -> ### Fixes
• feat / feature commits -> ### Features
• docs commits -> ### Docs (only if user-facing; skip changelog-only docs commits)
• chore / refactor / perf -> ### Internal (only if noteworthy; skip trivial ones)

Each item should be a concise, user-facing description — not a raw commit message. Rewrite commit messages into the bold-name-em-dash style. Group related commits into a single item when they address the same thing.

Skip commits that are only changelog/release housekeeping.

4. Preview

Show the drafted changelog section to the user in full. Ask: "這樣 OK 嗎？要調整什麼？"

Do NOT proceed until the user approves.

5. Update CHANGELOG.md

Insert the new version section below [Unreleased]. If there's an [Unreleased] section covering this module's changes, move those items into the versioned section.

6. Commit

git add CHANGELOG.md
git commit -m "docs: vX.Y.Z changelog"

7. Test

go test -race ./...

If tests fail, stop and tell the user.

8. Tag and push

Ask the user before pushing: "要 push 了，確認？"

git push && git tag vX.Y.Z && git push --tags

9. Create GitHub release

gh release create vX.Y.Z --title "Release vX.Y.Z" --notes-file -

Pipe the changelog section content (just this version's notes) as the release notes.

After release, tell the user: "Release vX.Y.Z 已發布" and provide the release URL.

Important rules

• Never modify existing version sections — they match published releases
• Date format — YYYY-MM-DD, use today's date (timezone: Asia/Taipei)
• Commit message — always docs: vX.Y.Z changelog
• v2 releases must be on release/v2 branch — checkout first