软件版本号命名：给个人项目初学者制定清晰的 A.B.C.D 规则

内容总结生成中

你看见的，不仅是一个总结

给个人项目制定版本号时，先不要急着把数字往上加。你真正要完成的是建立一套自己能长期坚持、读者也能看懂的记录方式：看到版本号，就能大致判断这次更新是重大改版、新增功能、修复问题，还是仍处于测试阶段。本文适合刚开始维护个人软件、应用或工具的初学者，重点讨论 A.B.C.D 这类多段版本号，以及 Alpha、Beta、RC 和正式版标识的使用方法。

先确定一套固定的版本结构

最容易执行的方式，是先约定每一段数字代表什么，再规定什么情况下允许增加。一个常见的三段式结构是：

主版本号.次版本号.修订号
A.B.C

可以这样理解：

例如，你的个人工具最初发布为 1.0.0。之后增加了一个导出功能，可以改为 1.1.0；发现导出结果有一个错误，修复后改为 1.1.1。

这里的重点不是数字本身，而是保持解释一致。你不需要让每个项目都遵循完全相同的行业规则，但需要避免今天把第二段当作功能版本，下一次又把它当作日期使用。

A.B.C.D 什么时候值得使用

四段式版本号可以写成：

主版本号.次版本号.修订号.构建或日期号
A.B.C.D

前三段仍然表示项目变化，第四段用于补充一次更具体的发布记录。它可以表示构建次数，也可以表示日期，但两者不要混用。

用作构建号

如果你经常发布内部测试版本，可以让第四段单纯递增：

1.2.0.1
1.2.0.2
1.2.0.3

这种写法适合记录同一组功能经过了几次打包或测试。即使前三段没有变化，第四段也能区分不同文件或不同测试结果。

用作日期号

如果你更关心某个版本大约在什么时候生成，也可以使用日期形式：

1.2.0.20250308

不过，日期号通常会让版本变长，而且不能单独说明改了什么。对于个人项目，只有在你确实需要区分每日构建或多个同日版本时，才值得使用。

不要让第四段承担太多含义

下面这种写法就比较难长期维护：

1.2.3.20250308_beta_测试版_最终

它同时混入了数字、日期、阶段、说明词和状态判断。读者很难知道哪些内容属于版本号，哪些只是备注。

更清晰的做法是把信息分开：

1.2.3.20250308-beta

或者在发布说明中写：

版本：1.2.3
阶段：Beta
构建日期：2025-03-08

如果你的项目没有多次内部构建的需求，三段式版本号加阶段标识通常已经足够，不必为了“看起来专业”强行使用四段式。

按发布流程使用 Alpha、Beta 和 RC

数字版本号说明“改了多少”，阶段标识说明“现在成熟到什么程度”。两者解决的是不同问题。

Alpha：功能还在形成

Alpha 适合项目早期或功能仍在快速变化的阶段。此时可以已经有可运行内容，但功能可能不完整，界面、数据结构或使用方式也可能继续调整。

例如：

0.1.0-alpha
0.2.0-alpha.1

你可以把 Alpha 理解为“主要验证方向和功能可行性”。这个阶段不宜向读者承诺稳定体验，也不宜频繁改变版本号结构来表达每一个小变化。

Beta：功能基本成形

Beta 表示主要功能已经比较完整，接下来重点是发现问题、调整体验和验证稳定性。

例如：

0.9.0-beta
0.9.1-beta

在 Beta 阶段，如果只是修复问题，可以增加修订号；如果又加入了一个明显的新功能，则可以增加次版本号。阶段标识仍然保留，说明它还不是正式稳定版。

RC：准备发布正式版

RC 是候选发布版本，适合用于“功能基本冻结，只等待最后检查”的阶段。

例如：

1.0.0-rc.1
1.0.0-rc.2

如果第一个候选版本发现了问题，可以发布第二个候选版本。只有当你确认不再需要针对主要问题继续修改时，才将其转为：

1.0.0

正式版：去掉阶段标识

正式版通常直接使用数字版本号：

1.0.0
1.1.0
1.1.1

不要一边称它为正式版，一边继续保留 alpha 或 beta。例如，1.0.0-beta 和 1.0.0 应该代表两个明确不同的发布状态。

从一次实际发布开始判断数字

你可以按照下面的顺序处理每次更新。

第一步：先判断是否仍处于早期阶段

如果项目只有一个很粗略的原型，或者核心功能还没有形成，可以使用：

0.1.0-alpha

当功能逐渐可用，但仍然需要较多测试时，可以改为：

0.5.0-beta

这里的 不是“没有价值”的意思，而是提醒读者：项目的使用方式和功能边界仍可能变化。

第二步：判断是否新增功能

如果这次加入了用户能够直接感知的新能力，并且没有破坏原有用法，可以增加次版本号。

1.0.0 → 1.1.0

例如：

• 增加一个新的导出格式；
• 增加批量处理功能；
• 增加一个独立的筛选或搜索能力；
• 对已有功能做了较完整的体验改进。

如果只是修复按钮无效、结果显示错误等问题，不必增加次版本号。

第三步：判断是否只是修复和微调

对于不改变主要功能的修复，可以增加修订号：

1.1.0 → 1.1.1
1.1.1 → 1.1.2

适合使用修订号的情况包括：

• 修复一个明确的错误；
• 修正计算结果或显示细节；
• 改善异常情况下的处理；
• 修复更新后才发现的回归问题。

一次发布包含多个小修复时，也可以合并为一个修订版本，不需要每改一行内容就发布一个新数字。

第四步：判断是否需要主版本变化

主版本号适合表示一次明显的阶段变化，而不是“这次改动很多”这么模糊的感觉。

1.4.2 → 2.0.0

可以考虑增加主版本号的情况包括：

• 核心使用方式发生改变；
• 原有数据或配置不再适用；
• 删除了重要功能；
• 项目整体方向改变；
• 大范围改动导致旧用法无法继续使用。

如果只是增加了很多兼容功能，但原有用户仍然可以按原方式使用，通常不必直接升主版本号。

用一张变更表避免随手递增

当你不确定该改哪一段时，可以先记录变化，再决定版本号：

例如，某个个人记账工具的发布过程可以这样记录：

0.1.0-alpha     完成基本记录功能
0.2.0-alpha     增加分类和搜索
0.9.0-beta      主要功能基本完成
0.9.1-beta      修复统计结果显示问题
1.0.0-rc.1      功能冻结，开始最后检查
1.0.0            正式发布
1.0.1            修复正式版发现的小问题
1.1.0            增加周期记录功能

这样的版本历史比单纯写成 1.0.1、1.0.2、1.0.3 更容易回忆，也方便读者理解项目经历了哪些阶段。

发布前检查版本号是否自洽

每次发布前，可以用几分钟完成下面的检查：

1. 确认版本号格式没有改变。

如果一直使用 A.B.C，不要突然改成日期型或加入无法解释的数字。

1. 确认每一段数字的含义。

主版本、次版本、修订号和第四段构建号应该各司其职。

1. 确认阶段标识与项目状态一致。

仍在快速试验时不要写成正式版，已经正式发布也不要长期保留 Beta。

1. 确认本次变化与版本升级相匹配。

修复小问题不必升主版本，新增完整功能也不宜只随意增加一个构建号。

1. 确认变更记录写得清楚。

至少记下新增内容、修复内容和是否存在已知限制。

1. 保留上一个可用版本。

如果新版本出现问题，应能明确退回上一个版本，而不是继续覆盖原来的数字和记录。

初学者常见的混用方式

把日期号当成功能版本号

1.2.20250308 只能说明某个时间点，不一定能说明发生了什么变化。如果使用日期号，应提前规定它是第四段构建号，而不是临时插入到不同位置。

同时使用多套递增规则

例如，一次按功能增加第二段，下一次又按发布日期增加第三段，之后再按文件数量增加第四段。这样会让版本历史失去可读性。

选择一套简单规则后，即使项目规模很小，也应该坚持使用。

用版本号代替变更说明

1.3.0 本身不能告诉读者新增了什么。版本号只负责定位版本，具体变化仍应写在变更记录中：

1.3.0
- 增加批量导出
- 优化筛选条件保存
- 修复空数据时的显示问题

为了显得正式而过度细分

如果你的项目每周只发布一次，且没有复杂的内部构建流程，A.B.C 加上 Alpha、Beta 或 RC 已经够用。规则越复杂，越容易在后续发布中忘记自己当初的约定。

一套适合个人项目的简化方案

如果你还没有任何版本命名习惯，可以直接从下面这套规则开始：

A.B.C[-阶段]

约定为：

• A：重大变化或不兼容变化；
• B：新增功能或较大的兼容改进；
• C：问题修复和小范围调整；
• -alpha：功能仍在探索；
• -beta：功能基本完整，正在测试；
• -rc.1：候选正式版；
• 无阶段标识：正式版。

只有在确实需要区分构建次数或日期时，再扩展为：

A.B.C.D[-阶段]

其中 D 只负责构建号或日期号，不能同时承担功能级别和发布状态。

版本号的价值不在于看起来复杂，而在于它能把项目的变化讲清楚。对个人项目来说，能持续执行的简单规则，通常比一套经常被临时修改的“完整规范”更有用。