release

Release

Releasing is not just tagging; it is a quality gate process: security review→generate version→create Release.

---

Step 1: Pre-release checks

Before releasing, the following conditions must be confirmed:

准备发版
  │
  ├─ 1. 代码状态检查
  │   ├─ 工作区干净？（无未提交改动）
  │   ├─ 在正确的分支上？（main / release branch）
  │   └─ 已合并所有需要的 PR？
  │
  ├─ 2. CI 状态检查（如果有）
  │   └─ GitHub Actions 全绿？
  │
  ├─ 3. 安全审查
  │   └─ 提示用户：是否需要跑 security-audit？（上线服务强烈建议）
  │
  └─ 4. 测试验证
      └─ 核心功能是否经过验证？

Check command：

# 工作区状态
git status

# CI 状态（GitHub）
gh run list --limit 5

# 未合并的 PR
gh pr list

If any check fails,prompt the user to handle it before continuing, and do not force the release.

---

Step 2: Determine the version number

CalVer format

YYYY.MM.PATCH

Part	Meaning	Example
YYYY	Year	2026
MM	Month (no zero padding)	4
PATCH	Release number in the current month (starting from 1)	1, 2, 3...

Version number generation logic：

# 获取当前年月
YEAR=$(date +%Y)
MONTH=$(date +%-m)

# 查找当月已有的最大版本号
LATEST=$(git tag --list "${YEAR}.${MONTH}.*" --sort=-version:refname | head -1)

if [ -z "$LATEST" ]; then
  # 当月第一次发布
  VERSION="${YEAR}.${MONTH}.1"
else
  # 递增 PATCH
  PATCH=$(echo "$LATEST" | awk -F. '{print $3 + 1}')
  VERSION="${YEAR}.${MONTH}.${PATCH}"
fi

echo "版本号: $VERSION"

Example：

• 1st release in April 2026 → 2026.4.1
• 2nd release in April 2026 → 2026.4.2
• 1st release in May 2026 → 2026.5.1

---

Step 3: Generate Changelog

Extract from git log

# 获取上一个 tag 到 HEAD 的所有提交
PREV_TAG=$(git describe --tags --abbrev=0 2>/dev/null || echo "")

if [ -z "$PREV_TAG" ]; then
  # 没有历史 tag，取所有提交
  COMMITS=$(git log --oneline --pretty=format:"%s")
else
  COMMITS=$(git log ${PREV_TAG}..HEAD --oneline --pretty=format:"%s")
fi

Group by type

Based on the commit message's type(scope): desc format, automatically group:

# Changelog — v2026.4.1

## 新功能（Features）
- **auth**: 支持 OAuth2 第三方登录
- **export**: 用户数据导出功能

## 修复（Fixes）
- **login**: 修复密码错误时返回 500 的问题
- **cache**: 修复缓存 key 冲突

## 重构（Refactoring）
- **api**: 统一错误响应格式

## 其他
- **docs**: 更新 API 文档
- **test**: 补充登录模块测试用例

Grouping rules：

commit type	changelog group
feat	New features (Features)
fix	Fixes (Fixes)
refactor	Refactoring (Refactoring)
perf	Performance optimization (Performance)
docs, test, chore, ci	Other (can be omitted if there is no feat/fix/refactor)

Changelog output

• With GitHub: embed in the GitHub Release body
• Without GitHub: write to docs/changelog/YYYY-MM-DD-v<版本号>.md

---

Step 4: Create Release

Option A: GitHub Release (preferred)

# 创建 tag
git tag -a "v${VERSION}" -m "Release v${VERSION}"
git push origin "v${VERSION}"

# 创建 GitHub Release
gh release create "v${VERSION}" \
  --title "v${VERSION}" \
  --notes "$(cat <<'EOF'
<changelog 内容>
EOF
)"

Option B: Local Changelog file

If the project is not on GitHub or does not need a GitHub Release:

# 创建 tag
git tag -a "v${VERSION}" -m "Release v${VERSION}"

# 写入 changelog 文件
# 存入 docs/changelog/YYYY-MM-DD-v<版本号>.md

---

Step 5: Post-release

1. Notify the user: release complete, output the version number and Release URL
2. Update package.json / pyproject.toml(if the project requires syncing the version number to config files)
3. Reminder: if there are deployment steps that require manual action, list them

---

Complete release process

用户：发个版
  │
  ├─ Step 1: 发版前检查（代码状态 + CI + 安全）
  ├─ Step 2: 生成版本号（CalVer）
  ├─ Step 3: 生成 Changelog（从 git log）
  ├─ Step 4: 创建 Release（GitHub 或本地文件）
  └─ Step 5: 发版后处理

---

Relationship with other skills

task-finish（功能收尾）
  ↓
security-audit（发版前安全审查）
  ↓ 审查通过
release（本 skill — 发版）