软件版本代号，有的真的很有趣

厌工情绪积压，写点轻松的。

我一直没仔细去软件版本号的来历，稀里糊涂跟着公司定义的走。

但最近去下Ubuntu，看到Ubuntu 24.04(Noble Numbat)时楞了一下，怎么一个版本就跟高贵的袋食蚁兽扯上关系了。

看来这个版本号，是时候搞清楚它的背景了。

---

我们先说从常见的吧，三段式编码机制：R<major>.<minor>.<revision>

以AUTOSAR文档版本号为例，在19年以前我们看到CP文档通常是R4.3.0、R4.4.0等，刚好与上述三段式编码对应，其中：

• Major：主版本号，通常是架构变化\重大功能变化导致，版本号会递增，例如出现了无法兼容的API；
• Minor：次版本号，一般是当前版本新增功能、改进功能时递增，例如4.3.0 -> 4.4.0；
• revision：修正版本号，也叫patch，主要是Bug的修复时递增，例如4.4.0->4.4.1；

举个例子：开发时一般以0.1.0开始（我见过从0.0.0开始的），一直开发、修bug，版本号从0.1.0 -> 0.1.1 ->0.1.2->0.2.0，以此类推，直到当前功能都开发完毕且比较稳定了，第一个版本1.0.0就出来了，那如果后面发现bug，就可以1.0.1->1.0.2这样；如果架构变化导致出现了无法兼容的API，版本就可以1.0.2 -> 2.0.0。

这种命名方式应该是目前软件发版最常用的，它是在2009年由Tom Preston-Werner提出的语义化版本控制(SemVer)，通过规范Major、Minor、Patch的定义来解决兼容性问题。

但随着软件更新和发版速度越来越快，通过给版本号新增特征值来告知客户当前软件的成熟度也变成了一种趋势，常见的如α(Alpha版本--仍然需要测试，通常会邀请合作伙伴来参与)、β(Beta版本--功能完备、可能有bug)、RC(Release Candidate，最终发布的候选版本，一般会推出RC1、RC2两个版本)、GA(General availability，所有必要的活动已经完成了)等、RTM(Release to Manufacture)等。

---

回到Autosar文档版本，在19年11月以后，为了解决同一ECU中CP、AP平台的之间版本一致性问题，统一使用了Ryy-mm的机制，例如最近发布的R24-11，就是在24年11月发布的版本，哦，需要注意的是yy实际年份表示的是yy+2000。

不过呢，AutoSAR仍然用SemVer来表示内部释放版本，具体对应关系如下：

 最后，我们回过头来看Ubuntu的版本号，就能够发现，它也是使用Ryy-mm的机制，同时给每个版本号增加了一个好玩的名字（规则是形容词+动物名，这两个词首字母一样，按照字母表顺序进行），例如：

好了，奇奇怪怪没用的知识又增加了。