软件版本阶段与语义化版本(SemVer)

软件版本阶段

• Alpha版：预览版或内部测试版，一般不向外部发布，会有很多 bug。
• Beta版：公测版。消除了严重错误，但还是存在着一些缺陷，需要经过多次测试消除。
• RC版：Release Candidate 候选版本。也叫做 Gamma 版本。该版本已经相当成熟，基本上不存在导致错误的 bug，与即将发行的正式版相差无几。
• Release版：正式版本。

语义化版本

主版本号.次版本号.修订号

1. MAJOR：当你做了不兼容的API修改；
2. MINOR：当你做了向下兼容的功能性新增；
3. PATCH：当你做了向下兼容的bug修复。

语义化版本控制规范：

• 主版本号为零（0.y.z）的软件处于开发初始阶段，一切都可能随时被改变。这样的公共 API 不应该被视为稳定版。
• 1.0.0的版本号用于界定公共 API 的形成。这一版本之后所有的版本号更新都基于公共 API 及其修改内容。
• 修订号 Z（x.y.Z | x > 0）必须在只做了向下兼容的修正时才递增。这里的修正指的是针对不正确结果而进行的内部修改。
• 次版本号 Y（x.Y.z | x > 0）必须在有向下兼容的新功能出现时递增。在任何公共 API 的功能被标记为弃用时也必须递增。也可以在内部程序有大量新功能或改进被加入时递增，其中可以包括修订级别的改变。每当次版本号递增时，修订号必须归零。
• 主版本号 X（X.y.z | X > 0）必须在有任何不兼容的修改被加入公共 API 时递增。其中可以包括次版本号及修订级别的改变。每当主版本号递增时，次版本号和修订号必须归零。
• 先行版本号可以被标注在修订版之后，先加上一个连接号再加上一连串以句点分隔的标识符来修饰。标识符必须由 ASCII 字母数字和连接号 [0-9A-Za-z-] 组成，且禁止留白。数字型的标识符禁止在前方补零。先行版的优先级低于相关联的标准版本。被标上先行版本号则表示这个版本并非稳定而且可能无法满足预期的兼容性需求。范例：1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。

FAQ

我该如何处理即将弃用的功能？
弃用现存的功能是软件开发中的家常便饭，也通常是向前发展所必须的。当你弃用部份公共 API 时，你应该做两件事：

1. 更新你的文件让使用者知道这个改变
2. 在适当的时机将弃用的功能透过新的次版本号发布。在新的主版本完全移除弃用功能前，至少要有一个次版本包含这个弃用信息，这样使用者才能平顺地转移到新版 API。

npm中package.json文件依赖项版本号

版本号格式
major.minor.patch

version
必须匹配某个具体版本。如：1.0.0

~version
如果 minor 版本号指定了，那么 minor 版本号不变，而patch版本号任意。如：~1.1.1，表示>=1.1.1<1.2.0
如果 minor 和 patch 版本号未指定，那么 minor 和 patch 版本号任意。如：~1，表示>=1.0.0 <2.0.0

^version
版本号中最左边的非0数字的右侧可以任意。如：^0.1.1 ，表示>=0.1.1<0.2.0

x
x的位置表示任意版本。

*
任意版本。如：*，表示>=0.0.0的任意版本。

参考

• https://github.com/semver