软件包版本号语义化：解析包名的版本控制规范-linux运维-PHP中文网

语义化版本号核心是major.minor.patch三段式结构：major递增表示不兼容变更，minor递增表示新增向后兼容功能，patch递增表示仅修复缺陷且完全兼容。

软件包版本号语义化：解析包名的版本控制规范

软件包版本号的语义化，核心是让每个数字和符号都传达明确的工程意图——不是随意递增，而是告诉所有人“这次更新意味着什么”。

这是 Semantic Versioning（SemVer 2.0）的基石结构，适用于绝大多数 Android 应用、Java/Kotlin 库、Gradle 插件等：

MAJOR（主版本）：发生不兼容变更时才递增，比如删除公开 API、修改接口签名、重构核心模块（如从 Retrofit 1.x 升级到 2.x）。用户升级需主动适配，否则编译或运行失败。
MINOR（次版本）：新增向后兼容的功能，例如增加深色模式支持、接入新 SDK、开放某个内部能力为 public 方法。老用户无需改动即可使用新功能。
PATCH（修订版）：仅修复缺陷、优化性能或调整文案，不新增功能也不破坏兼容性。例如修复某机型闪退、修正时间格式错误、降低内存占用。

实际项目中常在 PATCH 后追加额外字段，提升可追溯性与发布控制力：

Refore网页转设计

一款AI图像与设计工具，主要用于一款加速产品 UI 设计迭代的工具，可以一键将任意网页和交互导入到 Pixso、MasterGo、即时设计、Figma，实现像素级还原，适合需要提升相关任务效率的用户。

下载

构建序号（BUILD）：如 1.5.2.237 中的 237，对应 CI/CD 流水线单次构建 ID，确保每次打包产物全局唯一，便于日志归因和符号表匹配。
预发布标记：测试阶段使用 -alpha、-beta、-rc 后缀，如 2.0.0-rc3。正式上架前必须移除后缀，否则 Google Play 等平台可能拒绝发布。
渠道或环境标识：多渠道分发时可加 -xiaomi、-debug、-staging，但注意 versionName 不影响安装逻辑，仅作识别用途。

Android 强制要求两套版本标识并行存在，作用完全不同：

versionCode（整数）：系统唯一判断能否覆盖安装的依据。必须严格单调递增（如 101 → 102 → 103），哪怕只是热修复补丁。建议采用自动递增策略（如 Git 提交数、CI 构建序号），避免人工维护出错。
versionName（字符串）：纯展示用途，用户在应用详情页看到的“1.5.2”或“2.0.0-beta”。它不参与安装校验，但需与 versionCode 保持逻辑对齐——例如 versionCode=105 的包，其 versionName 应反映对应语义层级（如 PATCH 修复后仍是 1.5.2，而非跳成 1.5.3）。
两者无数学关系：versionCode=1 可对应 versionName="0.1.0"，versionCode=999 也可对应 versionName="1.0.0"；关键在于团队约定清晰、文档可查、脚本可自动化。

很多团队踩过坑，根源在于混淆语义或脱离流程：

把 versionCode 当成“年月日”硬编码（如 20260618），导致跨年或多次发布当天无法递增，建议改用构建序号或 Git commit count。
测试版 versionName 带 -beta 却未清理就上架，引发商店审核失败或用户困惑。
MINOR 升级时偷偷引入不兼容改动（如删掉一个 public 方法），破坏下游依赖稳定性。
多个分支并行开发时，未统一 versionCode 生成规则，造成灰度包与正式包 versionCode 冲突或倒置。