最近刷文章刷到了这个话题，很多观点吧，实在是不能苟同。
首先我们先理解一下这三个概念：
major：大版本号，比如1.0.0minor：小版本号，比如1.1.0patch：补丁版本号，比如1.0.1
请注意：
-
一旦有不兼容的更新，那么
major就必须增加。 -
新功能的增加，需要增加
minor，比如1.1.0。 -
修复 bug，需要增加
patch，比如1.0.1。
1. 拿v0.x.x作为生产版本
既然是语义化版本号，而且大家经常把 从0到1 （狗头：和成都无关）挂嘴边，那么我可以这么认为，还没到 1，那就证明你还在为生产版本做准备，还没有计划好发布正式的版本。
你可以在 0.x.x 版本中，做任何事情，包括：
- 验证式开发，可行性的验证
- 写BUG 修BUG 在代码里聊天
- 不带任何脑子的设计和开发
- 开发者自行参与的测试
但当你需要其他任何人(除团队内开发人员以外的其他任何人)参与测试（含内测、公测、），或者是发布正式版本，必须将 major 升到 1。
因为你要开始对其他人负责了
你依然可以自由的使用 alpha beta rc 等关键词来表示 1 之后的其他非正式版本：
| 版本标识 | 示例 | 可执行操作 | 说明 |
|---|---|---|---|
| alpha | v1.0.0-alpha.1 | 功能增减 BUG修复 | 内部测试版本，一般不对外发布，一般只团队内的测试人员介入 |
| beta | v1.0.0-beta.1 | 功能增减 BUG修复 | 公开测试版本，团队外的部分人员可介入 |
| rc | v1.0.0-rc.1 | BUG修复 | 候选版本，团队外的所有人员可介入 |
| release | v1.0.0 | BUG修复 | 正式版本，团队外的所有人员可介入 |
2. major的变化意味着什么
无论是产品级版本号，还是作为依赖项目的版本号，都需要尊重这个原则：
一旦有不兼容的更新，例如 破坏性更新、产品品牌色变更、Logo变更、产品主名称变更、产品唯一标识变更、产品归属权变更 等， 那么 major 就必须增加。
2.1 破坏性更新
当产品作为被依赖项时，下列情况下必须增加 major：
- API发生变更，依赖方必须做出调整
- 配置文件发生变更，依赖方必须做出调整
- 数据结构发生变更，依赖方必须做出调整
- 其他任何需要依赖方调整才能正确运行的情况
2.2 产品信息变更
当然，如果是对外发布的软件，但下列情况发生时也需要增加 major：
- 删除了某个功能，影响用户使用
- 需要卸载早期版本才能正常使用当前版本
- 产品名称发生变更，影响用户记忆
- 产品品牌色/Logo/名称变更，影响用户记忆
- 产品唯一标识（包名、ID等）变更
- 产品归属权、域名、备案等信息变更
2.3 其他情况
minor超过99时，不得不增加major- 其他需要合理增加
major的情况
3. major 变更大小有什么意义
首先，我是不认可 “v2.0 到 v3.0 是一个巨大的、突破性的变化，而 而 v125.0 到 v126.0 的不兼容更新 显得微不足道” 这个说法的。
3.1 人类对于数字变化的感知
这个所谓的感知在 major 上我是不认同的。
首先，major 的变化只用于表示大版本更新，至于变化有多大，应该在类似 CHANGELOG 的文件中明确说明，而不是根据 major 的变化量来判断。
其次，作为依赖方，应该在被依赖项目的版本号 major 变化时，能及时的查阅对方提供的 CHANGELOG 文件，从而做出相应的调整。
如果，被依赖方 需要在版本号上做 强提醒 来通知依赖方此次变更很多，达到所谓的 吓死人的 变更，可以直接跳过下一个 major 即可。例如直接从 v2.0 升级到 v4.0。
3.2 从 v1.0 升级到 v100.0，实在草率
不知道其他人怎么看待，在我的认知中，随意变更 major 本身就是一个不负责任或产品形态不稳定的状态。
如果变更很多，说明产品本身出现了很多设计上的问题，没有经过大量的思考、测试、验证就发布了，我认为这不是个什么好习惯。完全可以使用长时间的 alpha beta rc 来验证、测试，可以减少正式版本的 major 变更。
4. 各种各样的版本号
4.1 年份类的版本号
一般用在产品类的版本号上，例如 2024.10.1，表示是2024年10月1日发布。（当然，也有直接使用 2024.10 表示是 2024年的第10个版本）
比如 QQ2005，SQL SERVER 2005 等。
4.2 语义化版本号
semver 是语义化版本号，它定义了版本号 major.minor.patch 的语义化规则。现在大部分的软件版本都使用的方式。
4.3 其他花里胡哨的
不得不提前端开发者头疼的 ECMAScript 版本号：
ES5 ES6 ES2020 ESNext...
不过，最好玩的版本号，应该是 USB 版本号了吧？
USB1.0 USB2.0 USB3.0 USB3.1 USB3.1 Gen 2 USB3.1 Gen 2x1
哦，如果你写过类似 驱动程序 或者是做 硬件配套程序 等，你可能还会见过这些版本号：
主版本号.功能版本号.芯片架构.内存规格.联网方式.供电方式。。。。。
看起来就像这样： v3.2.ARM.8G.WIFI.DC5V
5. 最后
也是最近刷文章看到了一些话题有感，半夜睡不着于是水了这篇文章。
最后的最后，
前端挺喜欢搞些所谓新时代的东西。
