如何定义版本号

版本格式:主版本号.次版本号.修订号,版本号递增规则如下:

  1. 主版本号:当你做了不兼容的 API 修改,
  2. 次版本号:当你做了向下兼容的功能性新增,
  3. 修订号:当你做了向下兼容的问题修正。

先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面,作为延伸。

如何定义版本号

主版本号为零(0.y.z)的软件处于开发初始阶段,一切都可能随时被改变。这样的公共 API 不应该被视为稳定版

1.0.0 的版本号用于界定公共 API 的形成。这一版本之后所有的版本号更新都基于公共 API 及其修改内容

修订号 Z(x.y.Z | x > 0)在只做了向下兼容的修正时才递增。这里的修正指的是针对不正确结果而进行的内部修改

次版本号 Y(x.Y.z | x > 0)在有向下兼容的新功能出现时递增。在任何公共 API 的功能被标记为弃用时也递增。也“可以 MAY ”在内部程序有大量新功能或改进被加入时递增,其中包括修订级别的改变。每当次版本号递增时,修订号归零。

主版本号 X(X.y.z | X > 0)在有任何不兼容的修改被加入公共 API 时递增。其中包括次版本号及修订级别的改变。每当主版本号递增时,次版本号和修订号归零

预发版本号

在常规的版本号命名之上还有一个特殊类别,叫做预发版本号(prerelease version)。它表示当前版本是一个不稳定的版本,使用它时需要注意风险。

预发版本号的格式是 <major>.<minor>.<patch>-<tag>,即前半部分和常规版本号相同,然后跟上连接符 -,后面再跟上字母数字点号连接符([0-9A-Za-z-.])。

一个典型的预发版本号形如 1.0.0-beta.1。建议使用这种 <major>.<minor>.<patch>-<stage>.<num> 的形式。其中 <stage> 一般选用:alphabetarc

预发版本号是常规版本号的附属,因此在版本的大小比较上,仍然先比较常规版本号部分;对于预发标记部分的比较,则是根据 ASCII 字母表中的顺序来进行。