软件版本号：SemVer、日期版本与构建标识

版本号用于标识交付物；选择规则之前，应明确对外承诺的是 API 兼容性、发布日期，还是一次具体构建。三者可以关联，但不能混为同一套排序规则。

SemVer 的适用前提

语义化版本采用 MAJOR.MINOR.PATCH，前提是项目定义了公开 API。对于稳定版本，兼容的修复增加 PATCH，兼容的新功能增加 MINOR，不兼容的公开 API 变更增加 MAJOR；增加高位时低位归零。“工作量很大”或“功能很重要”本身不是破坏兼容性的证明。

变化	版本示例
兼容修复	1.2.3 → 1.2.4
兼容新增能力	1.2.3 → 1.3.0
不兼容 API 变化	1.2.3 → 2.0.0

0.y.z 可以用于初始开发阶段，不必为所有项目立即写成 1.0.0；初始阶段的公开 API 稳定性需要明确说明。

预发布与构建信息

1.2.3-alpha.1 < 1.2.3-beta.1 < 1.2.3-rc.1 < 1.2.3
1.2.3+build.20261002

预发布标识位于减号之后；同一核心版本的预发布优先级低于正式版。加号后的构建元数据不参与 SemVer 优先级比较，因此不能用它表达“应该自动升级到这个更高版本”。1.2.3.20261002 是自定义四段版本，不是标准 SemVer。

日期版本与构建编号

日期版本（例如 2026.10）适合突出发布周期，但不直接保证兼容性。内部构建编号（例如 build-2048）适合追踪流水线产物；应另外记录对应 Git 提交、构建配置和平台。不要把四段内部编号直接当作通用依赖范围语言使用。

发布前检查

先说明本次修改对使用者是否兼容，再更新版本与变更日志；构建、测试后给对应提交打标签，并让产物携带相同版本与提交标识。已发布版本的内容应保持不变，发现问题应发布新的版本，便于复现和回滚。

原笔记把“大功能”等同主版本升级、要求一律从 1.0 开始，并混用了四段版本与 SemVer；以上按 SemVer 2.0.0 规范 修正。日期版本与内部编号是项目选择，需要独立声明规则。