软件版本

标准格式

大部分软件的版本都采用了如下的三段式结构：

MAJOR.MINOR.PATCH

其中：

• MAJOR为主版本号，一般是软件部分功能重写，导致不再兼容

  例如，当你使用了Gradle新的大版本，由于语法调整，可能你之前写的脚本无法再运行了，需要调整。

• MINOR为次版本号，一般是进行了向下兼容的功能新增

• PATCH为修订号，一般是修复了某个功能的bug，也是向下兼容的

• 也可以在版本后面新增版本描述，例如：1.0.0-alpha

  以下为一些常见描述：

  • alpha，内部测试版本
  • beta，对外公测版本
  • rc，预发售版本（Release Candidate）
  • stable，稳定版本
  • LTS，长期支持版本（Long-term Support）

详情可以参考Github版本标准：语义化版本 2.0.0。

时间格式

另外还有一种用的比较多的是时间格式，即：

YEAR.MONTH.MAJOR.PATCH

即开发软件的年、月为前两位，接下来是在该月的第几个版本，最后是修复版本号。

例如ClickHouse的版本：22.8.11.15-lts、22.11.2.30-stable

ClickHouse采用这种版本原因可能是，ClickHouse是非常依赖社区的一个软件，社区会频繁贡献很多新功能，所以发布新版本非常频繁，一年可能会发布十多个稳定版本（参考：Which ClickHouse Version to Use in Production?），也就是说小步快走的模式，而不是传统的规划未来版本，然后按规划开发。所以，这种模式就很难确定大版本的界限，按传统的版本号就不太好确定。

所以，时间格式在不好确定大版本界限的时候，是更加简单、方便的。

当然时间格式也有一些缺点：

• 如果某个版本出现了问题，就很难找到与之兼容的稳定版本，需要去查看冗长的版本变更日志。反观传统的三段式结构，本身大版本、小版本就考虑了兼容性问题，所以同一个大版本号下的基本上就为兼容版本
• 两个团队同时开发一个软件，那么同一时间开发的两个大版本的时候，版本号就太过密集，例如22.10.1和22.10.2是可能是两个大版本

其他格式

主版本号不再表示重大变更

例如Linux，从 3.0 开始主版本号就没有什么特别的意义，只是当次版本号太大时，Linus觉得过大的数字会让他困扰，因此就"进位"到主版本号了。比如，2.6.39 之后就是 3.0，3.19 之后就是 4.0，4.20 之后就是 5.0。（参考：Linux 的版本号和 520 | Linux 中国）当然这种版本号的命名带有Linus的个人主义色彩。

无限接近于π

图灵奖的获得者Donald Knuth开发的排版系统，TeX，采用的版本号就是无限接近于π，首个版本是3，当前版本是3.141592653。Donald Knuth使用这种方式是因为他认为，一个不变的稳定系统要比引入新功能更重要，TeX预计只会进行少量的更新。

适合我们的格式

我认为开发Web系统，版本号采用时间格式更加合适，理由如下：

• 无需为版本号头疼

  实际中，起版本号的时候，经常头疼一个问题就是，是大版本还是小版本，而采取时间格式不存在这个问题，只有新版本和修复版本。

• 使用者无需考虑兼容性

  我们知道，看不出兼容信息，是时间格式最大的缺点，而由于我们的场景并非客户端软件，而是Web+后端服务，使用者无需考虑兼容性问题。

• 更加具有业务意义

  看版本号就知道哪些是本月要发版的版本，技术方面，看一个不熟秀的系统的版本号，也知道哪些是最近的版本，而且不同系统之间的版本号更加统一，不存在有的系统v1.6，有的系统v6.1。

但是对于客户端软件，由于用户要考虑兼容性问题，还是传统的三段式格式好一些。

References

1. Github版本标准：语义化版本 2.0.0
2. 知乎：Linux 的版本号和 520 | Linux 中国
3. 维基百科：TeX
4. 知乎：版本号定义规则思考