Starter Versions and the Boot BOM
You may have noticed that none of library-service's starters has a version number. That is not an oversight. Spring Boot manages the versions of hundreds of libraries for you, and the one number you do choose, the Boot version itself, decides all the others.
The rule
Choose one Boot version; it chooses every other version for you.
Every Boot release publishes a bill of materials (BOM), spring-boot-dependencies, a long list of libraries with versions that were tested together. Your build imports it in one of two ways.
With Maven, the usual way is to inherit from the Boot parent:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>3.5.6</version>
</parent>With Gradle, apply the Boot plugin together with the dependency-management plugin:
plugins {
id 'org.springframework.boot' version '3.5.6'
id 'io.spring.dependency-management' version '1.1.7'
}From then on, spring-boot-starter-web gets the matching Spring Framework, Jackson and Tomcat versions, and a plain driver such as postgresql gets its tested version too, as long as it appears in the BOM.
Spring Boot 3 has two baseline facts worth remembering: it needs Java 17 or newer, and it uses the Jakarta EE namespace, so imports read jakarta.persistence.Entity and jakarta.validation.constraints.NotBlank, not the old javax.*. A library built for Boot 2 that still uses javax.* will not work with Boot 3.
When you really must change one managed version, for example to pick up a security fix before the next Boot release, override its version property instead of hard-coding the dependency:
<properties>
<jackson-bom.version>2.19.2</jackson-bom.version>
</properties>The shortcut
To upgrade, change one number and run the tests. Bump the Boot version in the parent or plugin, let the BOM move everything else together, and read the release notes for anything deprecated or removed.
Change one number
Move the parent from
3.4.xto3.5.x.
The trap is pinning a version by hand on a managed dependency, <version> inside a starter or a library the BOM already covers. The next Boot upgrade leaves that one library behind, and the mismatch surfaces as a strange NoSuchMethodError at runtime.
Drills
Answer fast — trust the rule.
Why do starters in a Boot project usually have no <version>?
What is the minimum Java version for Spring Boot 3?
In a Boot 3 entity class, which import is correct?
You need a newer Jackson for a security fix before the next Boot release. What is the cleanest change?
Remember
- Choose one Boot version; it chooses every other version for you.
- Upgrade by changing one number, reading the release notes, and running the tests.
- Trap: hand-pinned versions of managed libraries, which drift on the next upgrade.