常规提交规范下，库版本升级通常使用minor或major提交类型，具体取决于升级的范围：minor：用于向后兼容的新增功能或改进（例如：1.2.0→1.3.0）。major：用于不兼容的更改或重大重构（例如：1.0.0→2.0.0）。如果升级仅包含修复和小改进，且不破坏现有功能，则使用patch（如1.2.0→1.2.1）。举例说明：新增API但不破坏现有代码→minor移除旧API或修改行为→m

在 Python 库开发中遵循 Conventional Commits 规范时，版本号升级（如 `pyproject.toml` 中的 `version` 字段变更）应优先使用语义明确、工具友好的 `release` 类型提交，而非泛化的 `chore`——这不仅精准传达“发布新版本”的核心意图，还能更好支持自动化发布流程、提升 CHANGELOG 生成准确性、增强 Git 历史可追溯性，并已被 Angular、Nx 等主流项目及 Conventional Commits 官方示例采纳为最佳实践。

在遵循 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 不仅是规范允许的扩展类型，更是语义精准、工具友好、团队可维护性更强的专业选择。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~