Spring Projects Version Naming Scheme – Spring项目的版本命名方案

最后修改: 2020年 2月 10日

中文/混合/英文(键盘快捷键：t)

1. Overview

1.概述

It is common to use Semantic Versioning when naming release versions. For example, these rules apply for a version format such as MAJOR.MINOR.REVISION:

在命名发布版本时，通常会使用Semantic Versioning。例如，这些规则适用于诸如MAJOR.MINOR.REVISION的版本格式。

  • MAJOR: Major features and potential breaking changes
  • MINOR: Backward compatible features
  • REVISION: Backward compatible fixes and improvements

Together with Semantic Versioning, projects often use labels to further clarify the state of a particular release. In fact, by using these labels we give hints about the build lifecycle or where artifacts are published.

与语义版本学（Semantic Versioning）一起，项目经常使用标签来进一步澄清某一特定版本的状态。事实上，通过使用这些标签，我们对构建生命周期或者工件的发布地点进行了提示。

In this quick article, we’ll examine the version-naming schemes adopted by major Spring projects.

在这篇快速文章中，我们将考察主要Spring项目所采用的版本命名方案。

2. Spring Framework and Spring Boot

2.Spring框架和Spring Boot

In addition to Semantic Versioning, we can see that Spring Framework and Spring Boot use these labels:

除了语义版本控制（Semantic Versioning）之外，我们还可以看到Spring Framework和Spring Boot也使用这些标签。

  • BUILD-SNAPSHOT
  • M[number]
  • RC[number]
  • RELEASE

BUILD-SNAPSHOT is the current development release. The Spring team builds this artifact every day and deploys it to https://repo.spring.io/ui/native/snapshot.

BUILD-SNAPSHOT是当前的开发版本。Spring团队每天都会构建这个工件并将其部署到https://repo.spring.io/ui/native/snapshot。

A Milestone release (M1, M2, M3, …) marks a significant stage in the release process. The team builds this artifact when a development iteration is completed and deploys it to https://repo.spring.io/ui/native/milestone.

里程碑发布（M1、M2、M3……）标志着发布过程中的一个重要阶段。当一个开发迭代完成后，团队会构建这个工件并将其部署到https://repo.spring.io/ui/native/milestone。

A Release Candidate (RC1, RC2, RC3, …) is the last step before building the final release. To minimize code changes, only bug fixes should occur at this stage. It is also deployed to https://repo.spring.io/ui/native/milestone.

候选发布版（RC1、RC2、RC3……）是构建最终发布版之前的最后一步。为了尽量减少代码变化，在这个阶段只应进行错误修复。它也被部署到https://repo.spring.io/ui/native/milestone。

At the very end of the release process, the Spring team produces a RELEASE. Consequently, this is usually the only production-ready artifact. We can also refer to this release as GA, for General Availability.

在发布过程的最后阶段，Spring团队制作了一个RELEASE。因此，这通常是唯一可用于生产的工件。我们也可以把这个版本称为GA，即General Availability。

These labels are alphabetically ordered to make sure that build and dependency managers correctly determine if a version is more recent than another. For example, Maven 2 wrongly considered 1.0-SNAPSHOT as more recent than 1.0-RELEASE. Maven 3 fixed this behavior. As a consequence, we can experience strange behaviors when our naming scheme is not optimal.

这些标签是按字母顺序排列的，以确保构建和依赖管理器能正确判断一个版本是否比另一个版本更新。例如，Maven 2错误地认为1.0-SNAPSHOT比1.0-RELEASE更新。Maven 3修正了这种行为。因此，当我们的命名方案不理想时，我们会遇到一些奇怪的行为。

3. Umbrella Projects

3.伞状项目

Umbrella projects, like Spring Cloud and Spring Data, are projects over independent but related sub-projects. To avoid conflicts with these sub-projects, an umbrella project adopts a different naming scheme. Instead of a numbered version, each Release Train has a special name.

伞状项目，如Spring Cloud和Spring Data，是超过独立但相关的子项目的项目。为了避免与这些子项目的冲突，伞状项目采用了不同的命名方案。每个Release Train都没有编号的版本，而是有一个特殊的名字。

In alphabetical order, the London Subway Stations are the inspiration for the Spring Cloud release names — for starters, Angel, Brixton, Finchley, Greenwich, and Hoxton.

按照字母顺序，伦敦地铁站是春之云发布名称的灵感来源–首先是Angel、Brixton、Finchley、Greenwich和Hoxton。

In addition to Spring labels shown above, it also defines a Service Release label (SR1, SR2…). If we find a critical bug, a Service Release can be produced.

除了上面显示的Spring标签，它还定义了一个服务发布标签（SR1，SR2…）。如果我们发现一个关键的错误，就可以产生一个服务发布。

It is important to realize that a Spring Cloud release is only compatible with a specific Spring Boot version. As a reference, the Spring Cloud Project page contains the compatibility table.

必须认识到，Spring Cloud 版本只与特定的 Spring Boot 版本兼容。作为参考，Spring Cloud 项目页面包含兼容性表。

4. Conclusion

4.总结

As shown above, having a clear version-naming scheme is important. While some releases like Milestones or Release Candidates may be stable, we should always use production-ready artifacts. What is your naming scheme? What advantages does it have over this one?

如上所示，有一个清晰的版本命名方案是很重要的。虽然有些版本如里程碑或候选版本可能是稳定的，但我们应该始终使用可用于生产的工件。你的命名方案是什么？它比这个方案有什么优势？