在遵循 Conventional Commits 规范的 Python 库开发中，版本号更新（如 pyproject.toml 中的 version 字段变更）推荐使用 release 类型提交；chore 虽然常见且合法，但语义不够精准，长期来看 release 更符合意图、更易被自动化工具识别。
在遵循 conventional commits 规范的 python 库开发中，版本号更新（如 `pyproject.toml` 中的 `version` 字段变更）推荐使用 `release` 类型提交；`chore` 虽然常见且合法，但语义不够精准，长期来看 `release` 更符合意图、更易被自动化工具识别。
当您执行一次库版本升级（例如从 0.3.1 升至 0.3.2），本质上是在发布一个新版本——这不仅涉及元数据变更，还通常伴随 CHANGELOG 更新、Git tag 创建、GitHub Release 发布等交付动作。因此，提交类型应体现“发布”这一高层意图，而非笼统归为日常维护任务。
✅ 推荐写法（语义清晰、社区趋势明确）：
release: bump version to 0.3.2
⚠️ 可用但非最优写法（技术上合规，但语义弱化）：
chore: bump version to 0.3.2
? 补充说明：Conventional Commits 规范明确允许自定义类型（除强制的 feat 和 fix 外），release 已被 Angular、Nx、Nx.dev 等主流项目广泛采用，并被 Conventional Commits 官方文档示例 引用。相较之下，chore 因含义宽泛（涵盖 CI 配置、依赖清理、脚本修复等），易导致提交信息分类模糊——Angular 团队早在 2023 年就正式弃用 chore 用于版本提交，理由正是“过度使用、丧失区分度”。
? 实践建议：
- 若使用自动化发布工具（如 release-please-action 或 semantic-release），请确认其对 release 类型的支持程度（当前主流工具均已原生支持）；
- 在 .releaserc 或 GitHub Action 配置中显式声明 release 为有效发布类型，避免误判；
- 配套提交可附加 scope 以标识模块粒度（如 release(python): bump version to 0.3.2），增强可追溯性；
- 始终确保版本变更提交单独成 commit，不与功能或修复混杂，便于 git bisect 和自动化解析。
总之，release 不仅是规范允许的扩展类型，更是语义精准、工具友好、团队可维护性更强的专业选择。
