hotplex-releaselisted

# HotPlex 发布工作流 ## 前置条件 - `gh` CLI 已认证并有 repo 访问权限 - 已安装 `make` 和 `go` 1.26+ - 所有测试通过 (`make check`) - 工作目录干净（无未提交的更改） ## 分支保护策略 **为什么分支保护很重要**：在非 main 分支创建标签会导致发布混乱，因为： 1. 标签应该指向稳定的、已合并到 main 的代码 2. CI/CD 流程期望在 main 分支上触发 release workflow 3. 避免在 feature 分支上意外发布不完整的版本 **分支判断流程**： 1. 在工作流开始时，检查当前分支： ```bash git branch --show-current ``` 2. **如果在 `main` 上**：执行完整工作流（步骤 1–8），包括创建 tag 和 release。 3. **如果不在 `main` 上**（feature 分支、release prep 分支等）：仅执行步骤 1–5（版本确定、变更收集、changelog 撰写、版本统一、验证）。然后： - 将版本 bump + changelog 作为**准备提交**提交（例如 `chore: prepare release vX.X.X`） - **不要**创建 git tag — 标签只能在 main 上创建 - **不要**推送 tag 或触发 GitHub Release — 这会在错误的分支上触发 CI - 通知用户："Release preparation committed on `<branch>`。Tag and publish after merging to main." 4. **合并到 main 后**：fast-forward 或 checkout main，然后只执行步骤 6（tag）和步骤 7（推送 tag + GitHub Release） ## 步骤 1：确定下一个版本 **为什么需要确定版本**：语义化版本号帮助用户和依赖者理解变更的影响范围。错误的版本号会导致： - 依赖者错过重要更新（将 major 标记为 minor） - 或者遇到破坏性更改（将 breaking change 标记为 patch） 从 `cmd/hotplex/main.go:16`（`version` 变量）读取当前版本。 应用 [语义化版本](https://semver.org/)： - **Patch** (`v1.1.0` → `v1.1.1`)：Bug 修复、安全补丁、无新功能 - **Minor** (`v1.1.0` → `v1.2.0`)：新功能、向后兼容的更改 - **Major** (`v1.1.0` → `v2.0.0`)：破坏性更改 在继续之前与用户确认新版本。 ## 步骤 2：收集变更 **为什么收集变更很重要**：完整的变更收集确保： 1. Changelog 包含所有重要更改，不会遗漏任何修复或功能 2. 可以准确评估版本级别（patch/minor/major） 3. 为用户提供清晰的升级路径和影响分析 4. 避免在发布后发现遗漏重要 commit 运行以下命令以收集自上次发布以来的所有变更： ```bash # 获取最后一个 release tag LAST_TAG=$(git tag --sort=-version:refname | head -1) #