Conventional Commits 规范下库版本更新应使用的提交类型

在遵循 Conventional Commits 规范的 Python 库开发中，版本号更新（如修改 pyproject.toml 中的 version 字段）推荐使用 release 类型提交，语义更精准；chore 亦可接受，但 release 更具意图明确性与行业实践一致性。

版本号更新这件事，在遵循 Conventional Commits 规范的 Python 库开发里，其实有个挺微妙的取舍。修改 `pyproject.toml` 里的 `version` 字段，到底该用 `release` 还是 `chore`？行业共识是：`release` 更精准，`chore` 也能凑合，但前者在语义清晰度和实际工程落地中，明显更胜一筹。

想想看，当你执行一次正式发布——比如把库版本从 0.3.1 升级到 0.3.2——这个动作本质上是一个发布事件（release event），而不是一次普通的日常维护。虽然 Conventional Commits 官方文档并没有强制规定 `release` 类型，但它在社区里早已成为事实标准，尤其是在那些强调语义化发布流程的项目中，几乎人手一份。

✅ 推荐写法（语义清晰、意图明确）

release: v0.3.2

或是更完整的格式，带上作用域和正文，方便自动化工具解析：

release(python-library): bump version to 0.3.2
- Update pyproject.toml version field
- Prepare for GitHub release and changelog generation

⚠️ chore 并非错误，但局限性明显

• chore 的本意是“构建、工具、依赖等辅助性任务”，比如更新 CI 配置、清理临时文件这类活儿。
• 把版本发布归类为 chore，很容易弱化它的重要性，而且提交日志读起来语义模糊——Angular 团队早就明确弃用 chore 用于发版了（参见 commit dff6ee3）。
• 自动化工具（比如 release-please、semantic-release）通常优先识别 release 或者 feat/fix + ! 组合来触发发布逻辑，release 类型能更可靠地被识别，减少误判。

? 实践建议

• 在 CI/CD 流程中集成支持 Conventional Commits 的发布工具，例如：
  • release-please-action（自动创建 Release PR、生成 CHANGELOG、推 tag）；
  • semantic-release（需要配置 Python 插件）；
• 所有发布提交都应附带 GPG 签名，并打上对应的语义化标签（比如 v0.3.2），确保可追溯性。
• 如果团队已经长期使用 chore 且没有自动化依赖，保持一致性也未尝不可。但新项目，建议直接上 release，提升协作时的语义质量。

总结一下：release 是目前最契合版本发布的 Conventional Commit 类型——既符合规范的扩展性原则，又具备清晰的上下文表达力，是专业 Python 库工程实践里一个相当稳妥的选择。