一、什么是语义化版本语义化版本Semantic Versioning简称 SemVer是一套国际通用的版本号命名规范让版本号本身就能传达信息。核心思想看到版本号就知道这次更新的性质和影响范围。二、标准格式完整格式主版本号 . 次版本号 . 修订号 - 预发布标识 构建元数据 MAJOR . MINOR . PATCH - prerelease build举例2.5.3-beta.120240115 │ │ │ │ │ │ │ │ │ └─ 构建元数据可选 │ │ │ └────────── 预发布标识可选 │ │ └───────────── 修订号 │ └─────────────── 次版本号 └───────────────── 主版本号大多数情况用简化版主.次.修订如2.5.3。三、三个核心数字详解1. 主版本号MAJOR何时 1做了不兼容的重大改动。场景说明架构重构整个应用重写不兼容旧数据旧版数据无法迁移界面彻底改版完全不同的使用方式删除重要功能移除了用户依赖的功能规则主版本 1 时次版本和修订号归零。1.9.5 → 2.0.0 重大更新后面归零2. 次版本号MINOR何时 1增加了新功能但向下兼容旧功能照常用。场景说明新增功能模块加了个新页面/新特性增加可选配置多了些设置项性能优化明显的体验提升规则次版本 1 时修订号归零主版本不变。1.5.8 → 1.6.0 新功能修订号归零3. 修订号PATCH何时 1只做了bug修复或微小改动功能不变。场景说明修复bug解决崩溃、错误修正文字改个错别字安全补丁修复漏洞规则只有修订号 1前面都不变。1.5.2 → 1.5.3 修bug只动最后一位四、演变示例完整生命周期0.1.0 → 开发初期第一个内部版本 0.5.0 → 开发中功能逐步完善 1.0.0 → 首次正式发布 1.0.1 → 修复了登录bug 1.0.2 → 修复了闪退问题 1.1.0 → 新增了分享功能 1.1.1 → 修复分享功能的小bug 1.2.0 → 新增了夜间模式 2.0.0 → 重大改版全新UI 2.0.1 → 改版后的bug修复观察规律修bug → 动最后一位加功能 → 动中间位末位归零大改版 → 动第一位后面全归零五、预发布标识大项目重点正式发布前通常有多个测试阶段用后缀标识区分常见阶段标识标识全称含义稳定性alpha内测版早期版本功能不全bug多⭐beta公测版功能基本完整仍在测试⭐⭐⭐rcRelease Candidate候选版接近正式无重大问题⭐⭐⭐⭐无正式版稳定发布⭐⭐⭐⭐⭐带编号的预发布同一阶段可能有多次迭代用数字编号1.0.0-alpha.1 → 第1个内测版 1.0.0-alpha.2 → 第2个内测版 1.0.0-beta.1 → 第1个公测版 1.0.0-beta.2 → 第2个公测版 1.0.0-rc.1 → 第1个候选版 1.0.0 → 正式版发布顺序从早到晚alpha beta rc 正式版 越往右越稳定越接近发布六、构建元数据了解即可用号附加构建信息如构建时间、Git提交号1.0.020240115 → 加上构建日期 1.0.0build.152 → 加上构建编号 1.0.0-beta.1a1b2c3d → 预发布 Git提交哈希特点构建元数据不影响版本优先级纯粹是记录信息。七、大项目为什么要严格遵守 SemVer1. 团队沟通高效用户报bug了问他版本号 他说 2.3.1-beta.2 → 立刻知道2.3.1的第2个公测版还没正式发布2. 判断影响范围从 → 到用户感知1.0.0 → 1.0.1修bug放心更新1.0.0 → 1.1.0有新功能值得更新1.0.0 → 2.0.0大变化可能要重新适应3. 依赖管理其他项目引用你的库时靠版本号判断兼容性我依赖 1.x.x 版本 → 1.5.0 可以升2.0.0 不能自动升可能不兼容八、在 Android 项目中配合 versionCode大项目常把versionName 编码进 versionCode让两者关联编码策略示例格式约定主(1位)_次(2位)_修订(2位)versionName 1.5.2 编码计算 主版本 1 → 1 次版本 5 → 05 修订号 2 → 02 versionCode 10502更多对照versionNameversionCode计算方式1.0.0100001_00_001.5.2105021_05_022.0.0200002_00_002.3.15203152_03_15好处看到 versionCode 20315立刻反推出版本是 2.3.15。在 gradle 中自动生成android{defaultConfig{// 定义版本各部分defmajor2defminor3defpatch15// 自动计算 versionCodeversionCode major*10000minor*100patch// 结果2*10000 3*100 15 20315// 自动拼接 versionNameversionName${major}.${minor}.${patch}// 结果2.3.15}}优势只改 major/minor/patch 三个变量versionCode 和 versionName自动同步生成不会出错。九、版本比较规则当需要判断两个版本谁更新时SemVer 有明确规则1. 逐位比较从左到右2.1.0 vs 2.0.9 → 主版本相同(22) → 次版本 1 0 → 结论2.1.0 更新2. 正式版 预发布版1.0.0 vs 1.0.0-beta.1 → 正式版 1.0.0 更新没有后缀的更新3. 预发布版内部比较1.0.0-alpha 1.0.0-beta 1.0.0-rc 1.0.0十、常见错误示范错误写法问题1.0→1.00加0没有意义混乱1.5→1.10想表示比1.5大很多应理解为1.10 1.5第二位105✅但易误解修bug却改主版本违反语义误导用户加功能却只改修订号用户以为只是修bugv1.0和1.0混用前缀不统一十一、核心总结语义化版本 主.次.修订让版本号自带含义。三位数字的规则主版本重大不兼容更新后面归零次版本新增功能且兼容修订归零修订号仅修bug预发布标识alpha内测beta公测rc候选 正式版。大项目好处沟通高效、判断影响、依赖管理。可配合 versionCode把版本号编码成整数如1.5.2→10502并用 gradle 自动生成。记忆口诀“大改动进大位小修补进小位测试版加后缀”。
