前端版本号命名规范 总结

前端版本号命名规范 总结

版本号命名规范是软件开发中非常重要的一部分，它不仅帮助开发者管理代码版本，也便于用户了解软件的更新和变化。本文将详细介绍前端版本号命名规范，包括语义化版本（Semver）的各个组成部分及其使用场景。

版本号命名规范

开源项目示例

下图是目前最流行的前端框架之一的 vue 近期版本发布记录，截图来自npmjs.com

从上图不难看出：

• vue 的版本号通常由三位组成，形如：X.Y.Z。
• 版本是严格递增的，此处是：3.5.0 -> 3.5.1 -> 3.5.2。
• 在发布重要版本时，可以发布 beta、rc 等先行版本。
• beta 和 rc 等修饰版本的关键字后面可以带上次数和 meta 信息。
• 可以说，vue 发布版本时做的相当到位，版本给人的感觉非常清晰，也很严谨。这得益于 Semver（语义化版本）规范的功劳。

语义化版本规范

版本号通常由三个部分组成：主版本号（Major）、次版本号（Minor）和补丁版本号（Patch），格式为「主版本号.次版本号.补丁版本号」。

• 主版本号：当项目整体重写，或出现不向后兼容的改变时，增加主版本号。当主版本号为 0 时表示软件还处于开发阶段。
• 次版本号：表示功能更新，当出现新功能时，增加次版本号。
• 补丁版本号：表示小修改，如修复 Bug，只要有修改就增加补丁版本号。

先行版本号及编译版本号可以加到「主版本号.次版本号.补丁版本号」的后面，作为延伸。

先行版本

当要发布大版本或者核心的 Feature时，但是又不能保证这个版本的功能 100% 正常。这个时候就需要通过发布先行版本。

比较常见的先行版本包括：内测版、公测版和 RC 版本。Semver （Semantic Versioning 简写）规范中使用 alpha、beta、rc 来修饰即将要发布到版本。它们的含义是：

• alpha：内测版。此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的 Bug 较多，需要继续修改。
• beta：公测版。该版本相对于 alpha 版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的 UI，这个阶段的版本也会一直加入新的功能。
• rc：即 Release candidate，正式版本的候选版本。该版本已经相当成熟了，基本上不存在导致错误的 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 版。

版本准则

列举出比较实用的一些规则：

• 项目初始化后，版本号为
  0.1.0
  。
• 版本在
  1.0.0
  之前，说明项目在开发当中。
• 每次修改，必须新开一个新版本。
• 发布版的版本号采用
  X.Y.Z
  。
• X、Y 和 Z 为非负整数。
• 禁止在数字前方补零，比如将
  1.1.1
  写作
  1.01.1
  。
• 禁止留白，比如将
  1.1.1
  写作

1. 1.1
   。

• 版本发布需要严格递增，比如
  1.0.0
  ->
  1.0.1
  ->
  1.0.2
  。
• 先行版本发布的顺序为
  alpha
  ->
  beta
  ->
  rc
  ，比如：
  1.0.0-alpha
  ->
  1.0.0-alpha.1
  -> ... ->
  1.0.0-beta
  ->
  1.0.0-beta.1
  -> ... ->
  1.0.0-rc
  ->
  1.0.0-rc.1
  -> ... -> 1.0.0。

关于主版本号：

• 0.Y.Z
  ，0 开头的版本号意味着什么？
• 项目初始化后的开发行为。
• 当前特性并不稳定，常被修改。
• 1.0.0
  ，什么时候使用正式版本号？
• 软件被正式用于生产环境。
• api 达到稳定标准。
• 递增
  ，什么时候主版本递增？
• 完成某一重要且稳定的特性。
• 废弃某一重要的特性。
• 阶段性存档。

关于次版本号：

• 0.1.0
  ，什么时候开始用？
• 项目被创建后的最小版本号为
  0.1.0
  。
• 递增
  ，什么时候次版本号递增？
• 新特性或新功能出现。
• 某一小特性达到稳定标准。
• 归零
  ，当主版本号递增时，则归零。

关于修订版本号：

• 递增
  ，仅在当前特性下做了向下兼容，或者修复 bug
• 归零
  ，当主版本号或次版本号递增后，修订号必须归零

关于先行版本号：

• 示例：1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。
• 什么时候用先行版本号？
• 非稳定版。
• 优先级低于标准版本。
• 格式约束。
• 必须为[0-9A-Za-z-]，通过
• 号连接在版本号的尾部。
• 常见的有 alpha，beta，rc 三个版本。

关于编译版本号：

• 示例：1.0.0-alpha+001、1.0.0+20130313144700、1.0.0-beta+exp.sha.5114f85。
• 什么时候用编译版本号？
• 当软件被新编译后，需加上编译版本号。
• 格式约束。
• 格式必须为[0-9A-Za-z-]，用

• 号连接，补充在版本号最末尾。