Partner – Trifork – NPI (cat=Spring Boot)
announcement - icon

Navigating the complexities of Spring can be difficult, even for seasoned developers.

If you need direct, practical help and guidance with your own Spring work, Trifork's CTO, Joris Kuipers, is running a closed-door call.

It's free, but it's limited to only 3 seats, so if you need it, I would join quickly and be sure to attend:

>>> CTO Spring Open Office Hour Session - Technical Guidance

With more than 15 years of leading custom software development projects involving Spring, Joris has gained a lot of real-world experience, and this call is about sharing and helping the community.


Course – LS – All

Get started with Spring 5 and Spring Boot 2, through the Learn Spring course:


1. Overview

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:

  • 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.

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

2. Spring Framework and Spring Boot

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

  • M[number]
  • RC[number]

BUILD-SNAPSHOT is the current development release. The Spring team builds this artifact every day and deploys it to

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

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

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.

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.

3. Umbrella Projects

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.

In alphabetical order, the London Subway Stations are the inspiration for the Spring Cloud release names — for starters, Angel, Brixton, Finchley, Greenwich, and 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.

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.

4. Conclusion

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?

Course – LS – All

Get started with Spring 5 and Spring Boot 2, through the Learn Spring course:

res – REST with Spring (eBook) (everywhere)
Comments are closed on this article!