新人开发者务必要知道的版本命名规则

前言

自行观看 语义化版本 2.0 即可以知道全面、准确的语义化版本的定义，这类只是对其进行归纳和总结，采用费曼学习法的方式方便我个人记忆。

语义化版本控制是什么？

程序开发并非是一次性的， 往往需要迭代进行更新与维护，而我们开发的程序不仅仅只是给自己使用，需要与他人合作时，或以插件、拓展的方式提供给开放社区的时，随着时间的推进、程序越来越复杂，就一定出现 依赖地狱，就会导致没有办法维护。 所以需要一套规则来简单的解决这个问题，所以
有了这个 “语义化版本” 这个规范，让版本可以通过命名就知道关联关系。

Tip: 如果公司项目并非对外开放且内部存在版本规范性要求，理应按照公司要求进行开发，而不应该生搬硬套，造成不必要的误会和损失。

版本号递增规则

版本号格式：主版本号.次版本号.修订号 （X.Y.Z）

1. 主版本号： 当做了不兼容的 API 的修改
2. 次版本号： 当做了向下兼容的功能性新增 （往往是新增特性，完善功能）
3. 修订号：当做了向下兼容的问题修正

先行版本号以及版本编译信息可以加到 “主版本号.次版本号.修订号” 的后面作为延申。

简化版语义版本控制规范

1. 必须有相关公共 API 文档，无论是代码中还是接口文档 ~
2. 标准的版本号必须（MUST）采用 X.Y.Z 格式， X Y Z 都不能小于零，禁止（MUST NOT ）补前导零。 X 是主版本号、Y 是次版本号、 Z 是修订号，每次更新都必须（MUST）按照以递增的方式， 例如 1.0.1 -> 1.0.1 -> 1.1.0
3. 版本发布后，禁止（MUST NOT）二次改变版本内容，以导致混乱，若发现错误也应该通知后，必须（MUST）新增新的版本号来进行发布
4. 开发阶段，必须(MUST) 使用主版本号为零（0.Y.Z）的方式进行开发，表达此时的版本是不稳定的，而标准稳定的第一个版本应该是 1.0.0 。（有时有先行版本号， 1.0.0-alpha）
5. 修订号 Z 必须（MUST）修复 BUG 时才进行递增。
6. 次版本号 Y 必须（MUST）新增功能，并兼容原来功能的时候进行递增修改，若标记弃用也必须（MUST）递增，递增后修订号必须归零。
7. 主版本号 Z 必须（MUST）新增功能，但不兼容原来版本的时候进行递增修改，递增后次版本号和修订号归零。

为什么要使用语义化的版本控制？

因为大家都遵循这个规范， 在我们开发程序中引入第三方包的时候就可以使用版本约束符号¹ ，以便于更好维护和管理项目。

常见问题

Q1：如果迭代更新非常快，例如一周一个版本，那我也要如此频繁更新吗？
A1：是的

Q2：开发完成后我一定要写公共文档吗？
A2：是的，不仅仅要写而且还要全面和正确，这个是开发责任感和前瞻性的问题，我已经见过很多次因为接口文档不清晰导致把 接口对接时间 浪费的问题

---

1. 常见的符号 > = < ~ * ， 当我们遵循语义化版本的时候才能正确使用，虽然已经约定俗成了 ~ ↩︎