使用规范的版本号，可以让软件的使用者清楚的知道软件的稳定性以及与之前已发布的版本之间的关系，减少沟通成本。
目前业界流行的版本规范是：语义化版本规范

概念

语义化的版本控制（Semantic Versioning），简称语义化版本，英文缩写为 SemVer。它是 GitHub 起草的一个具有指导意义的、统一的版本号表示规范。它规定了版本号的表示、增加和比较方式，以及不同版本号代表的含义。
语义化版本通过一组简单的规则及条件来约束版本号的配置和增长。这些规则是根据（但不局限于）已经被各种封闭、开发源码软件所广泛使用的惯例所设计。

格式

语义化版本格式：主版本号.次版本号.修订号（MAJOR.MINOR.PATCH）。
版本号递增规则如下：

  • 主版本号：做了不兼容的 API 修改（进行不向下兼容的修改）
  • 次版本号：做了向下兼容的功能性增加（API 保持向下兼容的新增及修改）
  • 修订号：做了向下兼容的问题修正（修复问题但不影响 API）

先行版本号及版本编译信息可以加到 “主版本号.次版本号.修订号” 的后面，作为延伸。
即完整格式为：X.Y.Z[-先行版本号][+版本编译元数据]

注意：

  • 主版本号、次版本号、修订号只能为非负的整数，且禁止在数字前方补零
  • 先行版本号和编译版本号只能是字母、数字，且不可以有空格

img

常见版本英文缩写：

  • Snapshot：快照
    • 也被称为开发版，处于开发阶段。这个版本的代码禁止用于生产环境。
  • Alpha (α)：内测版
    • 内部交流或专业测试人员测试使用。
  • Preview：预览版
    • 与 Alpha 类似，有时还会细分 M1，M2 版本。
  • Beta (β)：公测版
    • 专业爱好者大规模测试使用，存在一些 Bug，不适合一般用户使用。
  • Gamma (λ)
    • 比较成熟的测试版。
  • RC (Release Candidate)：候选版本
    • 处于 Gamma 阶段，该版本已经完成了全部功能并清除了大量的 Bug。
    • 到了这个阶段，只会修复 Bug，不会对软件做任何大的更改。
    • 一般来说，Alpha -> Beta -> Gamma 是迭代的关系，RC1 -> RC2 是取舍的关系。
  • Release：发行版本
    • 正式发行的版本，已经经过测试，一般不会出现严重的 Bug，适合一般用户使用。
    • 对于不开源的软件， Release 可能是带有免费使用时间限制的版本。
  • Stable：稳定版
    • 同 Release 版本。

一些例子：

1
2
3
1.0.0-alpha
1.0.0-alpha.1
1.0.0-alpha+001

规范

  • 标记版本号的软件发行后，禁止改变该版本软件的内容，任何修改都必须以新版本发行。
  • 主版本号为零（0.y.z）的软件处于开发初始阶段，一切都可能随时被改变，这样的公共 API 不应该被视为稳定版。1.0.0 的版本号被界定为第一个稳定版本，之后的所有版本号更新都基于该版本进行修改。
  • 修订号 Z（x.y.Z | x > 0）必须在只做了向下兼容的修正时才递增，这里的修正其实就是 Bug 修复。
  • 次版本号 Y（x.Y.z | x > 0）必须在有向下兼容的新功能出现时递增，在任何公共 API 的功能被标记为弃用时也必须递增，当有改进时也可以递增。其中可以包括修订级别的改变。每当次版本号递增时，修订号必须归零。
  • 主版本号 X（X.y.z | X > 0）必须在有任何不兼容的修改被加入公共 API 时递增。其中可以包括次版本号及修订级别的改变。每当主版本号递增时，次版本号和修订号必须归零。

如何确定版本号

  • 在实际开发的时候，建议你使用 0.1.0 作为第一个开发版本号，并在后续的每次发行时递增次版本号。
  • 当我们的版本是一个稳定的版本，并且第一次对外发布时，版本号可以定为 1.0.0。
  • 当我们严格按照 Angular commit message 规范提交代码时，版本号可以这么来确定：
    • fix 类型的 commit 可以将修订号 +1。
    • feat 类型的 commit 可以将次版本号 +1。
    • 带有 BREAKING CHANGE 的 commit 可以将主版本号 +1。

参考链接：https://semver.org/lang/zh-CN/