Introduction

Spring Boot and Spring Framework have different version numbers because they solve different problems. Spring Framework is the core application framework. Spring Boot is the opinionated platform that chooses a compatible set of versions, auto-configures common patterns, and packages an application more conveniently.

That means you normally do not choose a Spring Framework version independently inside a Boot application. You choose a Boot release, and Boot's dependency management selects the matching Spring Framework version for you.

Spring Framework Is The Core Library

Spring Framework provides the fundamental programming model:

• dependency injection
• configuration
• web MVC and webflux support
• transaction management
• data-access abstractions
• bean lifecycle and application context behavior

If you built a plain Spring application without Boot, you would manage many dependency versions and configuration choices yourself.

Spring Boot Is A Curated Platform

Spring Boot sits on top of the Spring Framework and provides:

• auto-configuration
• starter dependencies
• embedded server support
• production tooling such as Actuator
• managed dependency versions

That managed dependency aspect is the key to the version question. Boot is not just "another library." It is also a dependency-management layer that pins a tested set of compatible versions across the Spring ecosystem.

In Practice, Choose Boot First

In a normal Boot application, you usually define only the Boot version:

1<parent>
2    <groupId>org.springframework.boot</groupId>
3    <artifactId>spring-boot-starter-parent</artifactId>
4    <version>3.5.0</version>
5</parent>

Or, if you do not use the Boot parent, you import the Boot BOM:

1<dependencyManagement>
2    <dependencies>
3        <dependency>
4            <groupId>org.springframework.boot</groupId>
5            <artifactId>spring-boot-dependencies</artifactId>
6            <version>3.5.0</version>
7            <type>pom</type>
8            <scope>import</scope>
9        </dependency>
10    </dependencies>
11</dependencyManagement>

After that, Boot decides which Spring Framework modules are compatible. You typically do not pin spring-core, spring-web, or spring-context manually unless you have a very unusual reason.

Why The Version Numbers Differ

The version lines are separate because Boot releases on its own schedule and manages more than just Spring Framework. A Boot release also coordinates versions for:

• Spring Data
• Spring Security
• embedded servers
• JSON libraries
• logging libraries
• testing dependencies

So "Spring Boot version" is really the version of a tested dependency platform. "Spring Framework version" is the version of the core Spring library set inside that platform.

Overriding Framework Versions Is Risky

It is technically possible to override individual Spring Framework artifacts, but it is usually a bad default. Once you break away from Boot's managed dependency set, you become responsible for compatibility.

For example, forcing a different framework module version can create subtle problems:

1<dependency>
2    <groupId>org.springframework</groupId>
3    <artifactId>spring-web</artifactId>
4    <version>6.2.1</version>
5</dependency>

That might compile, but you have now stepped outside the combination Boot chose and tested. If you need a different Framework line, the cleaner move is usually to upgrade Boot itself to a release that already manages the desired Framework version.

How To Check The Actual Resolved Version

If you want to know which Spring Framework version your Boot app is really using, inspect the resolved dependencies rather than guessing:

mvn dependency:tree | grep spring-core

Or with Gradle:

./gradlew dependencies --configuration runtimeClasspath

This shows the real Framework artifacts brought in by the chosen Boot release.

Common Pitfalls

One common mistake is treating Spring Boot and Spring Framework as interchangeable products with matching version numbers. They are related, but not interchangeable. Another is manually pinning Spring Framework modules inside a Boot app without realizing Boot already manages them. Developers also often assume that newer individual framework artifacts are automatically better, when the safer path is usually upgrading the Boot platform that coordinates the whole dependency set. Finally, confusion often comes from reading framework documentation while working in a Boot app. The framework docs remain relevant, but the version-management responsibility is different in a Boot project.

Summary

• Spring Framework is the core library set, while Spring Boot is the curated application platform on top of it.
• In a Boot app, you usually choose the Boot version and let Boot manage the Framework version.
• Boot version numbers and Framework version numbers are different because they represent different release lines.
• Avoid overriding Spring Framework artifacts manually unless you really understand the compatibility impact.
• If you need a newer Framework line, the safest path is usually upgrading Boot rather than pinning individual Spring modules.