版本号的组成与迭代规则

命名规则（组成）

版本号通常存在以下几种命名规则，需要根据具体的产品进行选择：

主+次 规则

这类版本号使用最简单的主版本号+次版本号进行命名，具体格式为：

vx.y

其中， v 是version的缩写，意为“版本”，通常作为版本号的前缀。一般来说，我们使用小写v，它更加的常见，并符合社区的惯例。同时，大写V有时也可用，但小写更标准，能减少歧义。但具体使用小写还是大写甚至不写，应根据具体项目的规范决定。

x 为主版本号，代表产品主要的发布阶段或重大变更。它标识了产品的核心架构、主要功能或设计方向。不同主版本之间通常存在显著差异。

y 为次版本号，代表在同一主版本框架内增加的新功能或特性。它标志着功能的增强和扩展，但整体架构和兼容性保持不变。

主+次+修 规则

这类版本号在 主+次 的基础上增加了一个修订版本号，具体格式为：

vx.y.z

其中，新增的 z 为修订版本号，代表对当前版本的错误修复、安全补丁或微小改进。它不增加新功能，主要目的是提升软件的稳定性和安全性。

除此之外，还有一些可选的附加标识。

日期

这类版本号在前版本号的基础上增加了一个日期版本号，以主+次+修+日期为例，具体格式为：

vx.y.z.date

其中，新增的 date 为日期版本号，格式为 yyyymmdd ，用于记录修改项目的当日日期。

阶段

这类版本号在前版本号的基础上增加了一个阶段版本号，通常为希腊字母的英翻，这与前几个不同，它不以“.”连接，而是以“-”连接，以主+次+修+日期+阶段为例，具体格式为：

vx.y.z.date-stage

其中，新增的 stage 为阶段版本号，阶段版本号共有以下几种：

• Alpha：内部测试版。功能不完整，可能存在大量错误，仅限内部开发人员测试。
• Beta：公开测试版。主要功能已实现，面向部分外部用户收集反馈，但仍不稳定或功能不完整。
• RC：（Release Candidate）候选发布版。功能已冻结，主要进行最终的问题修复，接近正式版。（RC版曾经也被称为Gamma版，用于衔接希腊字母的表示方式，但现在已被弃用）
• GA：（General Availability）正式发布版，面向所有用户的正式版。（GA版曾经也被称为Omega版，用于衔接希腊字母的表示方式，但现在已被弃用）

阶段版本号后也可以接当前阶段的版本号，接上，格式为：

vx.y.z.date-stage.n

其中，新增的 n 为当前阶段的版本号，如Bata.1、Bata.2等。

说完以后，我们来举一个例子：v1.6.2.20260101-GA.1。

这个例子中，v（版本号前缀）1（主版本号）.6（次版本号）.2（修订版本号）.20260101（日期版本号）-GA（阶段版本号）.1（当前阶段的版本号）。

意为：在2026年01月01日发布的第1版1.6.2版本的正式发布版。

迭代规则

关于版本号的迭代，我们先以vx.y.z这种基础版本号进行讲解。

修订版本号（z）

迭代时机

当产品进行了向后兼容的问题修复时。

迭代规则

迭代时，修订版本号自增，主版本号与次版本号不变。

如，原版本号为v1.6.2，迭代后变为v1.6.3。

次版本号（y）

迭代时机

当产品新增了向后兼容的功能时。

迭代规则

迭代时，次版本号自增，主版本号不变，修订版本号归零。

如，原版本号为v1.6.2，迭代后变为v1.7.0。

主版本号（x）

迭代时机

当产品发生不兼容的API修改或重大更新时。

迭代规则

迭代时，主版本号自增，次版本号与修订版本号归零。

如，原版本号为v1.6.2，迭代后变为v2.0.0。

当版本号存在附加标识时，可根据以下规则进行迭代。

日期版本号

迭代时机

每次更新时。

迭代规则

迭代时，将日期版本号以yyyymmdd格式设为当日的日期。

当前阶段的版本号

迭代时机

当产品在当前阶段修改（包括增删改）内容时。

迭代规则

迭代时，当前阶段的版本号自增。

如，原版本号为v1.6.2-Beta.1，迭代后变为v1.6.2-Beta.2。

阶段版本号

迭代时机

当产品修改（包括增删改）内容跨度超过当前阶段时。

迭代规则

迭代时，阶段版本号按顺序更改，当前阶段的版本号归一。

如，原版本号为v1.6.2-Beta.2，迭代后变为v1.6.2-RC.1。

注：阶段版本号应根据Alpha -> Beta -> RC -> GA的顺序进行更改，中途可跳过，但不可逆向。

以上，就是版本号的命名规则与迭代规则。在实际使用中，应根据上述规则使用标准的版本号。

© 2026 小满工作室. All rights reserved.