软件版本号的命名看似随意实则背后有一套约定俗成的规则在支撑。这套规则的核心是语义化版本Semantic Versioning简称 SemVer它解决了因版本变更不透明而导致的“依赖地狱”问题。下面从核心规范讲起再延伸到业界常见的其他策略最后用一张 Mermaid 框图做总结。一、语义化版本规范SemVer 2.0.0这是目前开源社区和多数商业软件遵循的事实标准格式为MAJOR.MINOR.PATCH1. 基本组成与递增规则主版本号MAJOR当你做了不向下兼容的 API 修改时递增。例如删除了一个公开函数、改变了方法签名、修改了配置文件的解析方式导致依赖方必须修改代码才能适配。递增后次版本号和修订号归零。示例1.7.3→2.0.0次版本号MINOR当你做了向下兼容的功能性新增时递增。比如新增了一个可选接口、增加了一个不会破坏旧行为的配置项、标记某些 API 为废弃但仍可使用。递增后修订号归零。示例2.1.4→2.2.0修订号PATCH当你做了向下兼容的问题修正时递增。如修复了一个安全漏洞、纠正了某个边界条件的输出错误、优化了文档不影响行为等。示例2.2.0→2.2.12. 预发布版本Pre-release在MAJOR.MINOR.PATCH后加连字符-再接一系列由点.分隔的标识符。标识符只能包含 ASCII 字母数字和连字符[0-9A-Za-z-]。常见的标签有alpha内部测试版功能尚不稳定可能存在大量 bug。beta公开测试版功能基本冻结但需要外部反馈。rcRelease Candidate候选发布版若无重大问题则转为正式版。可以附加数字来区分迭代1.0.0-alpha.1、1.0.0-alpha.2、1.0.0-beta.1。优先级比较规则预发布版本的优先级低于与之关联的正式版。即1.0.0-alpha1.0.0。比较时从左到右依次比较每个标识符纯数字标识符按数值比较字母或字符串标识符按 ASCII 排序比较纯数字标识符的优先级始终低于非数字标识符。例如1.0.0-alpha1.0.0-alpha.11.0.0-alpha.beta1.0.0-beta1.0.0-beta.21.0.0-beta.111.0.0-rc.11.0.03. 构建元数据Build metadata在版本号末尾加加号再接点分隔的标识符如1.2.3build.20260101.abc。构建元数据不参与版本优先级比较只是用来区分不同构建环境如 CI 编号、时间戳、commit hash。两个仅在构建元数据上不同的版本被视为完全等同。4. 初始开发阶段的特殊约定当主版本号为0即0.y.z时代表软件处于初始开发期一切 API 都可能随时变动不保证任何稳定性。此时次版本号递增可能包含破坏性变更修订号递增也可能引入新功能。直到发布1.0.0才宣告公开 API 稳定。5. 版本范围与依赖声明在包管理工具npm, cargo, composer 等中可以利用 SemVer 定义兼容范围^1.2.3允许相同主版本下不小于1.2.3的最新版本即1.2.3 2.0.0。~1.2.3允许相同主次版本下不小于1.2.3的修订版即1.2.3 1.3.0。更精确的范围可用1.0.0 1.2.0等方式指定。二、其他常见的版本策略虽然 SemVer 已成主流但并非所有项目都严格遵循一些特定领域形成了自己的“约定俗成”策略特点典型用例日期版本版本号反映发布年月易于知晓时效性。格式常为YYYY.MM或YYYY.REV。Ubuntu (24.04)、Unity (2022.3 LTS)、JetBrains IDE (2024.1)营销版本以大版本号或品牌名称示人背后有独立的技术版本号。Windows 11内部 NT 10.0.22631、macOS Sequoia15.x快速滚动递增主版本号疯狂递增不再单独标记重大不兼容每次更新即为主版本。Chrome (125)、Firefox (126)、Edge奇偶策略偶数版本为稳定版奇数版本为开发版方便内核测试与迭代。现在已较少用。Linux 内核 2.4稳定 / 2.5开发2.6 后废除代号/昵称用通俗名称代替或补充数字版本便于记忆和传播。代号本身无大小关系。Android (Tiramisu)、Debian (Bookworm)、macOS (Ventura)这些策略并非完全孤立例如 Ubuntu 同时拥有代号Noble Numbat和日期版本24.04内核、编译器则有确切的主、次、修订版本。三、总结框图下面用一张 Mermaid 流程图将主要版本命名规则及其含义串联起来这张图概括了当前几乎所有约定俗成的版本命名规则以语义化版本为基石预发布标签和构建元数据提供更细粒度的阶段标识而日期、营销、快速递增、奇偶、代号等策略则在特定生态中各展所长。理解这些约定无论你是软件开发者、DevOps 工程师还是普通用户都能更精准地判断一次版本升级意味着什么。
上位机知识篇---软件版本号
发布时间：2026/5/29 6:39:57
软件版本号的命名看似随意实则背后有一套约定俗成的规则在支撑。这套规则的核心是语义化版本Semantic Versioning简称 SemVer它解决了因版本变更不透明而导致的“依赖地狱”问题。下面从核心规范讲起再延伸到业界常见的其他策略最后用一张 Mermaid 框图做总结。一、语义化版本规范SemVer 2.0.0这是目前开源社区和多数商业软件遵循的事实标准格式为MAJOR.MINOR.PATCH1. 基本组成与递增规则主版本号MAJOR当你做了不向下兼容的 API 修改时递增。例如删除了一个公开函数、改变了方法签名、修改了配置文件的解析方式导致依赖方必须修改代码才能适配。递增后次版本号和修订号归零。示例1.7.3→2.0.0次版本号MINOR当你做了向下兼容的功能性新增时递增。比如新增了一个可选接口、增加了一个不会破坏旧行为的配置项、标记某些 API 为废弃但仍可使用。递增后修订号归零。示例2.1.4→2.2.0修订号PATCH当你做了向下兼容的问题修正时递增。如修复了一个安全漏洞、纠正了某个边界条件的输出错误、优化了文档不影响行为等。示例2.2.0→2.2.12. 预发布版本Pre-release在MAJOR.MINOR.PATCH后加连字符-再接一系列由点.分隔的标识符。标识符只能包含 ASCII 字母数字和连字符[0-9A-Za-z-]。常见的标签有alpha内部测试版功能尚不稳定可能存在大量 bug。beta公开测试版功能基本冻结但需要外部反馈。rcRelease Candidate候选发布版若无重大问题则转为正式版。可以附加数字来区分迭代1.0.0-alpha.1、1.0.0-alpha.2、1.0.0-beta.1。优先级比较规则预发布版本的优先级低于与之关联的正式版。即1.0.0-alpha1.0.0。比较时从左到右依次比较每个标识符纯数字标识符按数值比较字母或字符串标识符按 ASCII 排序比较纯数字标识符的优先级始终低于非数字标识符。例如1.0.0-alpha1.0.0-alpha.11.0.0-alpha.beta1.0.0-beta1.0.0-beta.21.0.0-beta.111.0.0-rc.11.0.03. 构建元数据Build metadata在版本号末尾加加号再接点分隔的标识符如1.2.3build.20260101.abc。构建元数据不参与版本优先级比较只是用来区分不同构建环境如 CI 编号、时间戳、commit hash。两个仅在构建元数据上不同的版本被视为完全等同。4. 初始开发阶段的特殊约定当主版本号为0即0.y.z时代表软件处于初始开发期一切 API 都可能随时变动不保证任何稳定性。此时次版本号递增可能包含破坏性变更修订号递增也可能引入新功能。直到发布1.0.0才宣告公开 API 稳定。5. 版本范围与依赖声明在包管理工具npm, cargo, composer 等中可以利用 SemVer 定义兼容范围^1.2.3允许相同主版本下不小于1.2.3的最新版本即1.2.3 2.0.0。~1.2.3允许相同主次版本下不小于1.2.3的修订版即1.2.3 1.3.0。更精确的范围可用1.0.0 1.2.0等方式指定。二、其他常见的版本策略虽然 SemVer 已成主流但并非所有项目都严格遵循一些特定领域形成了自己的“约定俗成”策略特点典型用例日期版本版本号反映发布年月易于知晓时效性。格式常为YYYY.MM或YYYY.REV。Ubuntu (24.04)、Unity (2022.3 LTS)、JetBrains IDE (2024.1)营销版本以大版本号或品牌名称示人背后有独立的技术版本号。Windows 11内部 NT 10.0.22631、macOS Sequoia15.x快速滚动递增主版本号疯狂递增不再单独标记重大不兼容每次更新即为主版本。Chrome (125)、Firefox (126)、Edge奇偶策略偶数版本为稳定版奇数版本为开发版方便内核测试与迭代。现在已较少用。Linux 内核 2.4稳定 / 2.5开发2.6 后废除代号/昵称用通俗名称代替或补充数字版本便于记忆和传播。代号本身无大小关系。Android (Tiramisu)、Debian (Bookworm)、macOS (Ventura)这些策略并非完全孤立例如 Ubuntu 同时拥有代号Noble Numbat和日期版本24.04内核、编译器则有确切的主、次、修订版本。三、总结框图下面用一张 Mermaid 流程图将主要版本命名规则及其含义串联起来这张图概括了当前几乎所有约定俗成的版本命名规则以语义化版本为基石预发布标签和构建元数据提供更细粒度的阶段标识而日期、营销、快速递增、奇偶、代号等策略则在特定生态中各展所长。理解这些约定无论你是软件开发者、DevOps 工程师还是普通用户都能更精准地判断一次版本升级意味着什么。
：电池系统的仓储与物流管理规范)
