大家好，我是农村程序员，独立开发者，行业观察员，前端之虎陈随易。
- 个人网站 1️⃣：chensuiyi.me
- 个人网站 2️⃣：me.yicode.tech
如果本文能给你提供启发或帮助，欢迎动动小手指，一键三连 (点赞、评论、转发)，给我一些支持和鼓励，谢谢。
前端界的轮子大师，Anthony Fu 又做了件大事 时代语义版本控制。
什么意思呢？下面是文章第一段翻译后的原话：
如果您一直在关注我在开源方面的工作，您可能已经注意到我倾向于坚持使用零主要版本控制，例如
v0.xx。例如，在撰写本文时，
UnoCSS的最新版本是v0.65.3，Slidev是v0.50.0，unplugin-vue-components是v0.28.0。其他项目，例如
React Native是v0.76.5，sharp 是v0.33.5，也遵循这种模式。人们通常认为零主要版本表明该软件尚未准备好投入生产。
然而，这里提到的所有项目都非常稳定并且可以投入生产，已被数百万个项目使用。
文章很长，有时间的可以去读读原文 antfu.me/posts/epoch...
一句话总结就是：
目前的
语义版本控制有问题，我们需要新的时代语义版本控制。
那么目前的 语义版本控制 有什么问题呢？
先简单了解一下基本概念，语义版本控制 版本号由三部分组成：MAJOR.MINOR.PATCH。
MAJOR：当您进行不兼容的 API 更改时递增。MINOR：当您以向后兼容的方式添加功能时递增。PATCH：当您进行向后兼容的错误修复时增加。
比如 v1.2.3，1 是主版本，2 是次要版本，3 是修订版本。
以下原文：
然而，人类以对数字尺度的感知。
我们倾向于将
v2.0到v3.0视为一个巨大的、突破性的变化，而v125.0到v126.0则显得微不足道，尽管两者都表明语义版本控制中的 API 变化不兼容。这种看法可能会让维护者犹豫是否要针对较小的重大更改升级主要版本，从而导致在单个主要版本中累积许多重大更改，从而使用户升级变得更加困难。
相反，对于像
v125.0这样的东西，很难传达重大变化的重要性，因为跳转到v126.0看起来很小。
就是说，由于人类感知的问题，很多时候很难管理好，到底哪些更新放在哪个版本，导致小更新里面也混入了破坏式改动等问题。
以下原文：
在理想的情况下，我希望
语义版本控制有 4 个数字：EPOCH.MAJOR.MINOR.PATCH。
EPOCH版本用于那些重大公告，而MAJOR则用于可能并不重要的技术不兼容的 API 更改。这样，我们就可以采用更精细的方式来传达变更。
类似地，我们也有浪漫版本控制，建议
HUMAN.MAJOR.MINOR。但是，当然，对于整个生态系统来说，采用新的版本控制方案已经太晚了。
如果我们不能改变
SemVer(语义版本控制)，也许我们至少可以扩展它。我提出了一种新的版本控制方案，称为
Epoch Semantic Versioning，简称Epoch SemVer，中文名称时代语义版本控制。它建立在
MAJOR.MINOR.PATCH结构之上，将第一个数字扩展为EPOCH和MAJOR的组合。为了区分它们，我们使用第三个数字来表示
EPOCH，它给出了MAJOR范围从 0 到 99。这样，它遵循与
SemVer完全相同的规则，不需要任何现有工具进行更改，但提供了更精细的信息给用户。
格式如下：
EPOCH：当您进行重大或突破性更改时增加。MAJOR：当您进行较小的不兼容 API 更改时递增。MINOR：当您以向后兼容的方式添加功能时递增。PATCH：当您进行向后兼容的错误修复时增加。
例如，
UnoCSS将从v0.65.3过渡到v65.3.0(在 EPOCH 为 0 情况下)。SemVer 之后，补丁版本将成为
v65.3.1，功能版本将成为v65.4.0。如果我们引入了一些影响边缘情况的微小不兼容更改，我们可以将其升级到
v66.0.0以提醒用户潜在的影响。如果对核心进行重大修改，我们可以直接跳转到
v100.0.0以标志着新时代的到来并发布重大公告。我建议为每个非零
EPOCH分配一个代码名称，以使其更容易记住且更易于引用。这种方法为维护人员提供了更大的灵活性，可以有效地向用户传达更改的规模。
看懂了没有？说实话，我看了几遍都没搞清楚这个版本怎么理解。
不过在我的仔细推敲下，我的理解是这样的：
一共 4 个版本号，从左往右，第一个和第二个融合为一个，叫做 EPOCH * 100 + MAJOR，第三个和第四个跟以前的含义不变。
所以，时代语义版本 依旧是 x.x.x 三段式结构。
那么，当有向后 不兼容变更 的时候，由于不是非常重大的变更，很多维护者并不想升级大版，而是把这种不兼容性放到第二个数字中。
从而导致我们明明只是升级一个小版本，但运行却报错的问题。
所以，关于这个 不兼容变更，Anthony Fu 建议分成 2 个数字来控制，分别是 EPOCH 和 MAJOR。
默认情况下，EPOCH=0，那么 时代语义版本 跟原本的 语义版本 没有任何区别。
当你有较小的 不兼容变更 的时候，那就放心大胆地增加 MAJOR 版本，比如从 v1.0.0 升级到 v2.0.0。
当你有 较大的，颠覆性的，重大的，吓死人的 不兼容变更的时候，那就增加一次 EPOCH 版本。
比如现在的版本是 v2.5.6，按照 EPOCH * 100 + MAJOR 这个公式来说，此时 EPOCH=0，因为 0 * 100 + 2 = 2。
那么当有重大的，吓死人的更新的时候，第一个 吓死人 的 EPOCH 版本号就是 EPOCH=1，代入公式得到第一个数字是 1 * 100 + 0 = 100。
整个完整版本号就是 v100.0.0，继续更新，修订版本就是 v100.0.1、次要版本就是 v100.1.0，主要版本就是 v101.0.0 等等。
我们给每个 吓死人 的版本取个外号，比如叫做 死神。
那么下一个 吓死人 的版本是多少呢？就是 v200.0.0，外号叫做 如来。
每个重大更新，都有一个外号，这样更容易识别和记住不同的重大版本，让我们对版本的控制和印象，更加深刻。
这样一来，v100 到 v200 的升级，是不是比 v125 到 v126 的区别大多了，肉眼一看就知道是重大版本升级，维护者也可以更加放心大胆地更新 MAJOR 版本。
不得不说，不愧是 Anthony Fu，如此绝妙的想法，真是一个字：绝！
就在昨天，slidev 已经从 v0.51.0 升级到 v51.0.0，taze 已经从 v0.18.1 升级到 v18.1.0，ni 已经从 v0.23.2 升级到 v23.2.0 等等。
真是 知行合一 的典范啊！
Anthony Fu，前端永远的神，整个前端发展史，都有他浓墨重彩的一笔。