版本号定义规范
# 版本号定义规范
# 开源项目示例
下图是目前最流行的前端框架之一的 vue 近期版本发布记录，截图来自 npmjs.com (opens new window)：
（vue 版本发布记录）
从上图不难看出：
- vue 的版本号通常由三位组成，形如：X.Y.Z
- 版本是严格递增的，此处是：3.2.0 -> 3.2.1 -> 3.2.2
- 在发布重要版本时，可以发布 alpha，rc 等先行版本
- alpha 和 rc 等修饰版本的关键字后面可以带上次数和 meta 信息
- 可以说，vue 发布版本时做的相当到位，版本给人的感觉非常清晰，也很严谨。这得益于 Semver（语义化版本） 规范的功劳。
# 语义化版本
项目的版本号应该根据某些规则进行迭代，这里推荐使用语义化版本 (opens new window)规范，通过这个规范，用户可以了解版本变更的影响范围。规则如下：
- 主版本号（major）：当你做了不兼容的 API 修改。
- 次版本号（minor）：当你做了向下兼容的功能性新增，可以理解为 Feature 版本。
- 修订号（patch）：当你做了向下兼容的问题修正，可以理解为 Bug fix 版本。
先行版本号及版本编译信息可以加到「主版本号.次版本号.修订号」的后面，作为延伸。
# 先行版本
当要发布大版本或者核心的 Feature 时，但是又不能保证这个版本的功能 100% 正常。这个时候就需要通过发布先行版本。
比较常见的先行版本包括：内测版、灰度版本和 RC 版本。Semver 规范中使用 alpha、beta、rc（以前叫做 gama）来修饰即将要发布的版本。它们的含义是：
- alpha：内部版本。此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的 Bug 较多，需要继续修改。
- beta：公测版本。该版本相对于 alpha 版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的 UI，这个阶段的版本也会一直加入新的功能。
- rc：即 Release candiate，正式版本的候选版本。该版本已经相当成熟了，基本上不存在导致错误的 BUG，与即将发行的正式版相差无几，不会再加入新的功能了，主要着重于除错。
比如：1.0.0-alpha.0，1.0.0-alpha.1，1.0.0-beta.0，1.0.0-rc.0，1.0.p-rc.1 等版本。alpha，beta，rc 后需要带上次数信息。
最后，当经过这些先行版本的一系列测试之后，终归会有一个正式版本，是最终交付用户使用的一个版本，也就是 Release 版。
# 版本发布准则
列举出比较实用的一些规则：
- 标准的版本号必须采用 XYZ 的格式，并且 X、Y 和 Z 为非负的整数，禁止在数字前方补零，版本发布需要严格递增。例如：1.9.1 -> 1.10.0 -> 1.11.0。
- 某个软件版本发行后，任何修改都必须以新版本发行。
- 1.0.0 的版本号用于界定公共 API。当你的软件发布到了正式环境，或者有稳定的 API 时，就可以发布 1.0.0 版本了。
- 版本的优先层级指的是不同版本在排序时如何比较。判断优先层级时，必须把版本依序拆分为主版本号、次版本号、修订号及先行版本号后进行比较。
（完）