一、最通用：语义化版本 SemVer（Semantic Versioning 2.0.0）
绝大多数开源项目、后端服务、SDK、库都在用，格式：
MAJOR.MINOR.PATCH 例：
2.5.1、3.0.0、1.10.4
MAJOR（主版本号）：不兼容的 API / 架构变更，升级后旧代码会报错、不能直接兼容
比如接口入参大改、删除旧接口、数据库结构颠覆性改动 → +1
MINOR（次版本号）：向后兼容，新增功能
新增接口、新增配置、新增特性，老功能不受影响 → +1
PATCH（修订号 / 补丁号）：向后兼容，只修 Bug，不增功能
修复崩溃、逻辑错误、安全漏洞，无新能力 → +1
额外后缀（预发布版本），用
-连接：1.2.3-alpha、1.2.3-beta、1.2.3-rc1
alpha：内部测试版，不稳定，问题多
beta：公开测试版，主要功能完成，还有待修 bug
rc（Release Candidate，候选版）：认为基本稳定，准备正式发布，rc1、rc2…编译元信息，用
+：1.2.3+build20261028（构建号、git commit hash，不用于版本比较）
✅ 版本递增示例： 1.0.0 → 加功能 → 1.1.0 → 修 bug → 1.1.1 → 破坏性重构 → 2.0.0
二、日期版本（Calendar Version，CalVer）
适合客户端、固件、发行版、BI 平台、大版本产品，用日期做版本，不强调兼容性，一眼看出发布时间 常见格式：
YEAR.MONTH：Ubuntu24.04、26.10YEAR.MONTH.PATCH：2026.10.1YYYYMMDD：20261028（很多内部固件、镜像、运维包）
特点：每年 / 每月迭代，不区分兼容破坏性；适合持续滚动更新的产品。
三、简单流水号版本（Build 号）
格式：纯数字 v128、build-2345 多用于 CI/CD 流水线、测试包，每次打包自动 + 1，只代表先后顺序，没有兼容含义。
四、行业 / 厂商自定义版本规则
1. 四段式（国内政企、中间件、数据库、硬件很常见）
主。次. 修订。编译号 例：
7.0.0.421、5.6.3.202610前三段接近 SemVer，第四段是构建号、分支号、补丁包编号，信创、国产数据库、中间件大量使用这种。
2. 版本别名 + 版本号
比如：V3.2 铂金版、R2 SP3
R = Release（发行版）：
R1、R2SP = Service Pack（服务包 / 补丁集）：
SP1 SP2 SP3，批量修复 + 小增强，Windows、老商用软件常用
3. 分支版本标识
1.5.0-dev（开发分支）、1.5.0-snapshot（快照，Maven/Java 生态）、1.5.0-hotfix（紧急热修复）
snapshot：快照版，Java Maven 体系专属，随时会变，不建议生产依赖
五、版本前缀 v
习惯上加 v，比如 v2.3.1，只是标识，版本比较时忽略 v，v2.3.1 = 2.3.1，Git tag 最常用。
六、版本优先级排序（SemVer 规则）
正式版 > rc > beta > alpha 2.0.0-rc3 < 2.0.0 1.3.0-alpha2 < 1.3.0-beta1
七、快速对比表
八、常见坑提醒
不要混用两套规则：不要一会儿
2.1.0、一会儿20261028SemVer 小数点不是十进制：
1.10.0>1.9.0（不是 1.10 <1.9）hotfix 一般是 PATCH 升级：
2.1.1紧急修复线上问题snapshot、alpha、beta 一般禁止生产环境直接使用
本文原创作者：易君召，详见：https://www.yijunzhao.cn/authors/yijunzhao，转载请注明出处。
原文链接
欢迎访问 小易撩挨踢