版本号怎么提升
版本提升规则要落到例行动作上：修复类改动升修订号，兼容的功能新增升次版本号，不兼容的改动升主版本号，破坏性变更必须显式标注。版本号是给依赖方的契约信号，提前标好比事后解释省下大量沟通。
基本信息
| 判断依据 | 对外兼容性是否发生变化 |
|---|---|
| 修订号 | 缺陷修复类改动 |
| 次版本号 | 兼容的功能新增 |
| 主版本号 | 不兼容的破坏性改动 |
| 记录位置 | 提交信息与变更说明中的破坏性变更段落 |
典型使用场景
- 每次发布之前确定新版本号
- 破坏性改动需要在提交信息里显式标注
- 依赖方依据版本号判断升级风险
- 多个维护分支并行时各自独立递增版本号
- 用脚本根据提交约定生成候选版本号
判断示例
判断示例
# 缺陷修复 → 修订号加一
# 兼容的功能新增 → 次版本号加一，修订号归零
# 不兼容的改动 → 主版本号加一，其余归零
# 破坏性变更需在提交信息中显式标注段落提升对照
| 改动性质 | 版本位 | 依赖方需要做什么 |
|---|---|---|
| 缺陷修复 | 修订号 | 直接升级即可 |
| 兼容新增 | 次版本号 | 可以放心升级 |
| 不兼容改动 | 主版本号 | 必须先读迁移说明 |
| 仅内部重构 | 通常仍升修订号 | 对外无感知 |
版本号发布之后不要再改回同一版本号下的内容；一旦依赖方锁定过某个版本，内容替换会让双方对不上号。
修复回挑到多个维护分支时，各分支的版本号要独立递增，避免出现同号不同内容的情况。
发布前确认项
- 逐条核对本次改动里是否存在不兼容的接口变化
- 破坏性变更已写进提交信息与变更说明
- 版本号与标签一致，制品上标注的版本没有写错
- 维护分支上的补丁版本各自独立递增，互不冲突