Spring 项目版本命名规范解析

1. 概述

在发布软件版本时，语义化版本（Semantic Versioning） 是业界广泛采用的命名规范。典型的格式为 MAJOR.MINOR.REVISION，其含义如下：

✅ MAJOR（主版本号）：引入重大功能或不兼容的变更
✅ MINOR（次版本号）：新增向后兼容的功能
✅ REVISION（修订号）：仅包含向后兼容的修复和优化

除了基础的三段式版本号，很多项目还会附加标签（label）来标识该版本所处的生命周期阶段，比如是开发中、预发布还是正式发布。这些标签不仅帮助开发者理解版本稳定性，也影响构建工具（如 Maven）对依赖版本的解析行为。

本文将深入解析 Spring 生态中主流项目的版本命名策略，帮你避免踩坑，合理选择依赖版本。

2. Spring Framework 与 Spring Boot 版本命名

Spring Framework 和 Spring Boot 在遵循语义化版本的基础上，使用一套标准化的后缀标签来标识版本状态。以下是常见的标签及其含义：

标签	含义	使用场景	发布仓库
`BUILD-SNAPSHOT`	每日构建快照版	开发中最新代码，不稳定	snapshot 仓库
`M1`, `M2`, ...	里程碑版本（Milestone）	完成某个开发阶段的功能集成	milestone 仓库
`RC1`, `RC2`, ...	发布候选版（Release Candidate）	接近正式发布，仅修复关键 Bug	同上
`RELEASE` 或无后缀	正式发布版	可用于生产环境	Maven Central

关键要点

✅ BUILD-SNAPSHOT 是每日自动构建的开发版本，适合想尝鲜最新特性的开发者，但绝不推荐用于生产环境。
✅ Milestone（M1、M2…）表示阶段性成果，通常对应一个功能闭环的完成，可用于早期测试。
✅ Release Candidate（RC）是发布前的最后冲刺阶段，理论上只允许修复严重 Bug，不再引入新功能。
✅ RELEASE 才是真正的生产就绪版本，也称为 GA（General Availability），这才是你应该在项目中引用的稳定版本。

⚠️ 版本排序陷阱

这些标签的命名并非随意，而是经过精心设计——按字母顺序排列以确保构建工具能正确判断版本新旧。

例如：

RELEASE > RC > M > BUILD-SNAPSHOT （按字典序）
Maven 2 曾错误地认为 1.0-SNAPSHOT 比 1.0-RELEASE 更新，导致依赖混乱。
Maven 3 已修复此问题，但仍建议遵循标准命名，避免意外。

示例：Spring Boot 版本示例

<!-- 使用 SNAPSHOT 版本（需配置 snapshot 仓库） -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <version>3.4.0-BUILD-SNAPSHOT</version>
</dependency>

<!-- 使用里程碑版本 -->
<version>3.4.0-M1</version>

<!-- 使用发布候选版本 -->
<version>3.4.0-RC1</version>

<!-- 正式发布版本（推荐生产使用） -->
<version>3.2.5</version>

3. 伞形项目（Umbrella Projects）的版本策略

像 Spring Cloud 和 Spring Data 这类“伞形项目”，本身并不直接提供核心功能，而是整合多个独立但相关的子项目（如 Spring Cloud Netflix、Spring Cloud Gateway 等）。为了统一管理这些子项目的版本兼容性，它们采用了不同于常规语义化版本的命名方案。

核心机制：Release Train（版本列车）

🚆 想象一列火车，所有车厢（子项目）一起出发，共同前进。

每个“列车”有一个代号名称，而不是简单的数字版本号。这些代号通常来自某个主题系列。

Spring Cloud 的命名来源：伦敦地铁站名（按字母顺序）

Angel → Brixton → Camden → Dalston → Edgware → Finchley → Greenwich → Hoxton → Ilford → ...
当前最新可能是 2023.0.0（代号 Ilford），未来会是 L 开头的站点。

这种方式既有趣又便于记忆，更重要的是能清晰表达版本演进顺序。

新增标签：Service Release（SR）

除了标准标签外，Spring Cloud 还引入了：

✅ **SR1, SR2, ...**：服务发布版，用于在不升级主版本的前提下修复关键问题。

例如：

<spring-cloud.version>2022.0.3</spring-cloud.version>
<!-- 等价于 Hoxton.SR3 -->

❗ 重要提示：版本兼容性

Spring Cloud 并非独立运行，它严格依赖特定版本的 Spring Boot。官方提供了明确的兼容性矩阵：

Spring Cloud Release	Spring Boot Version
2023.0.x	3.2.x
2022.0.x	3.0.x - 3.1.x
2021.0.x	2.6.x - 2.7.x

📌 建议查阅 Spring Cloud 官方页面获取最新兼容性信息。

示例：Spring Cloud + Spring Boot 版本管理

<!-- 父 POM 中定义 BOM -->
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>2023.0.0</version> <!-- Ilford -->
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<!-- 子模块中无需指定版本 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>

4. 总结

Spring 生态的版本命名看似复杂，实则逻辑清晰、设计严谨：

✅ Spring Framework / Boot：基于语义化版本 + 标准标签（SNAPSHOT/M/RC/RELEASE）
✅ Spring Cloud / Data：采用 Release Train 模式，用代号命名 + SR 补丁机制
✅ 所有标签命名都考虑了字典序排序，避免构建工具解析错误
✅ 明确区分开发版与生产版，生产环境务必使用 RELEASE/GA 版本

给开发者的建议

⚠️ 不要盲目追新，SNAPSHOT 和 M 版本可能随时 break
✅ 合理利用 RC 版本做上线前验证
✅ 用好 BOM（Bill of Materials）管理伞形项目依赖
✅ 关注官方兼容性表格，避免版本错配导致启动失败

你的团队用的是哪种版本策略？是否遇到过因版本标签不当导致的依赖冲突？欢迎分享踩坑经历。

Persistence

REST

Security