软件版本号命名规范

  1. 总原则
  • 标准的版本号必须采用XYZ的格式，并且X、Y 和 Z 为非负的整数，禁止在数字前方补零
  • 版本是严格递增的，此处是：16.2.0 -> 16.3.0 -> 16.3.1
  • 在发布重要版本时，可以发布alpha, rc等先行版本
  • alpha和rc等修饰版本的关键字后面可以带上次数和meta信息
  • 版本的优先层级指的是不同版本在排序时如何比较。判断优先层级时，必须把版本依序拆分为主版本号、次版本号、修订号及先行版本号后进行比较。
  1. 软件版本阶段说明
  • Alpha版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。
  • Beta版: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。
  • RC版: 该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。
  • Release版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号®。
  1. 版本命名规范
    第一种：
    软件版本号由四部分组成：<主版本号><子版本号><阶段版本号><日期加希腊字母版本号>
*注意：* 希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。例如：1.1.1.051021_beta

第二种：
常规：完全的版本号定义，分三项：<主版本号>.<次版本号>.<修订版本号>，如 1.0.0

  1. 版本号定修改规则

  • 主版本号：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。
    例如：当你做了不兼容的 API 修改

  • 子版本号：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。
    例如：当你做了向下兼容的功能性新增，可以理解为Feature版本

  • 阶段版本号：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。
    例如：当你做了向下兼容的问题修正，可以理解为Bug fix版本。

  • 日期版本号:用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。

  • 希腊字母版本号:此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。

  1. npm包依赖
    当执行npm install package -S 来安装三方包时，npm 会首先安装包的最新版本，然后将包名及版本号写入到 package.json 文件中。
    比如，通过npm 安装 react 时：
    { "dependencies": { "react": "~16.2.0" } }
    复制代码项目对包的依赖可以使用下面的 3 种方法来表示(假设当前版本号是 16.2.0):

    • 兼容模块新发布的补丁版本：~16.2.0、16.2.x、16.2
    • 兼容模块新发布的小版本、补丁版本：^16.2.0、16.x、16
    • 兼容模块新发布的大版本、小版本、补丁版本：*、x

  2. npm包发布
    通常我们发布一个包到npm仓库时，我们的做法是先修改 package.json 为某个版本，然后执行 npm publish 命令。手动修改版本号的做法建立在你对Semver规范特别熟悉的基础之上，否则可能会造成版本混乱。npm 考虑到了这点，它提供了相关的命令来让我们更好的遵从Semver规范：

    • 升级补丁版本号：npm version patch
    • 升级小版本号：npm version minor
    • 升级大版本号：npm version major

    当执行 npm publish 时，会首先将当前版本发布到 npm registry，然后更新 dist-tags.latest 的值为新版本。

    当执行 npm publish –tag=next 时，会首先将当前版本发布到 npm registry，并且更新 dist-tags.next 的值为新版本。这里的 next 可以是任意有意义的命名（比如：v1.x、v2.x 等等）