参考链接 https://semver.org/lang/zh-CN/
语义化版本 2.0.0
(透过版本号的改变来传达信息.)
摘要
版本格式: 主版本号.次版本号.修订号
版本号递增规则如下:
1.主版本号: 做了不兼容的API修改.
2.次版本号: 做了向下兼容的功能性新增.
3.修订号: 做了向下兼容的问题修正.
规范摘要:以下以x.y.z表示版本号格式
- 上一级版本号递增时,下面的版本号必须归零.
- 举个简单的例子就可以展示语义化的版本控制如何让依赖地狱成为过去。假设有个名为“救火车”的函式库，它需要另一个名为“梯子”并已经有使用语义化版本控制的包。当救火车创建时，梯子的版本号为 3.1.0。因为救火车使用了一些版本 3.1.0 所新增的功能， 你可以放心地指定依赖于梯子的版本号大等于 3.1.0 但小于 4.0.0。这样，当梯子版本 3.1.1 和 3.2.0 发布时，你可以将直接它们纳入你的包管理系统，因为它们能与原有依赖的软件兼容。
- 0.y.z中 0 为主版本号,如 0.1.0 是初始化开发版本.并在后续的每次发行时递增次版本号.
- 主版本为0时,表示仍在快速开发阶段,每天都在改变API.
- 如果不小心把不兼容的改版当成了次版本号发行了该怎么办?
- 一旦发现自己破坏了语义化版本控制的规范,就要修正这个问题.
- 发行一个新的次版本号恢复向下兼容.
- 不能修改已发行的版本.
- 将有问题的版本号记录下来,告诉使用者问题所在,让他们知道这是一个有问题的版本.
- 如何处理即将弃用的功能?
- 更新文件说明让使用者知道这个改变.
- 在适当时机将弃用的功能透过新的次版本号发布.
- 在新的主版本完全移除弃用功能前,至少有一个次版本包含这个即将弃用的说明信息,这样使用者才能平顺地过渡到新版API中.