Spring Framework Support Lifecycle & Release History

How Does Spring Framework Handle Version Support and EOL?

Spring Framework is an open-source Java application framework maintained by Broadcom (formerly VMware Tanzu), providing the foundation for dependency injection, transaction management, and web development across the Spring ecosystem. Each major version line receives open-source (OSS) support for several years, with the final minor of each major line eligible for extended enterprise support beyond the OSS window.

Support runs in two distinct phases. During OSS support, the team publishes regular maintenance releases with bug fixes and security patches -- freely available to everyone. Once that window closes, a commercial enterprise support phase begins for qualifying versions, where critical and security-only fixes continue under a Tanzu Spring subscription. Refer to the release table above for exact End of OSS support and End of enterprise support dates per branch.

Spring Framework's support timeline directly drives the lifecycle of other Spring portfolio projects. Spring Security, Spring Data, and Spring Batch all align their EOL dates to the underlying Framework minor they depend on. Staying within an OSS-supported Framework version is the foundation for keeping your entire Spring stack covered.

References: Spring Framework official support page -- Spring project release calendar

What Are the Real Risks of Running an Unsupported Spring Framework Version?

Running an unsupported Spring Framework version means security vulnerabilities -- including remote code execution and path traversal CVEs like those disclosed in recent major releases -- will not receive patches from the Spring team.

Spring Framework is the runtime foundation for dependency injection, bean lifecycle, and request handling across your entire application. A known vulnerability at that layer is not isolated to a single feature; it is present everywhere the framework is invoked. Because CVE databases publish exact affected version ranges, EOL branches become a visible target.

Dependency drift compounds the problem over time. The Spring portfolio -- Spring Security, Spring Data, Spring Boot -- continues releasing updates that require a supported Framework version. Staying on an EOL Framework branch progressively blocks you from upgrading other parts of your stack, turning a single deferred migration into a multi-project freeze.

Integration breakage is also a real consequence. Jakarta EE namespace migration, new Servlet API versions, and updated JVM releases all assume a reasonably current Framework version. In practice, teams that defer past the EOL boundary often find the eventual migration significantly harder than it would have been at the OSS cutoff date.

What Happens After Spring Framework Reaches EOL?

After a Spring Framework version reaches full End of Life, all maintenance stops -- no patches, no security updates, no maintenance builds from the Spring team under either the OSS or enterprise channel.

Your existing applications will continue to run on the last published artifact. However, any CVEs discovered after that point are disclosed publicly with no upstream fix for the EOL branch. Community discussions may still surface workarounds, but the Spring team provides no guaranteed assistance or compatibility testing.

The enterprise support window -- visible in the End of enterprise support column of the release table above -- is the last line of coverage before full EOL. Teams on a Tanzu Spring subscription can continue receiving critical patches during that period without migrating immediately. Once that window also closes, there is no further patch source of any kind.

Migration Direction

The recommended upgrade path runs through Spring Boot. Boot's managed BOM pulls the correct Framework version transitively, so bumping the Boot version is the lowest-risk starting point. For major version boundaries -- particularly the move to the 6.x line, which introduced Jakarta EE namespaces and dropped Java 8 -- the Spring team publishes dedicated migration guides covering breaking API changes. Most teams find migrating in smaller steps across minor versions significantly easier than bridging multiple major versions in one go.

Tracking and Monitoring Spring Framework EOL Dates

The most reliable tracking practice is maintaining a version inventory across all applications and services that declare a Spring Framework dependency, direct or transitive.

Check the release table above regularly -- specifically the End of OSS support column -- and flag any branch within nine to twelve months of that date. That window is roughly the minimum lead time for a non-trivial Spring migration when accounting for testing and staged rollout. Setting a calendar reminder tied to the OSS cutoff date, rather than waiting for the EOL announcement, keeps upgrades planned rather than reactive.

Include Framework version review in architecture or dependency audits. Tools like mvn versions:display-dependency-updates or Dependabot can surface when a newer patch is available, but they do not report EOL status -- that check remains manual against the release table.

How To Check Your Spring Framework Version

Checking the exact Spring Framework version in your project takes one command and should be part of any routine dependency audit.

Maven

mvn dependency:tree | grep spring-core

Gradle

./gradlew dependencies --configuration runtimeClasspath | grep spring-core

Programmatically at runtime

import org.springframework.core.SpringVersion;

System.out.println("Spring Framework version: " + SpringVersion.getVersion());

Via Spring Boot BOM

If you are using Spring Boot, the Framework version is managed by the Boot BOM. To see the resolved version:

mvn help:effective-pom | grep spring-framework

Run these checks across development, staging, and production environments. Discrepancies between environments -- especially when a deployed artifact was built against a different BOM version -- are a common source of unexpected behavior after upgrades. Once you have the version string, cross-reference it with the release table above to confirm OSS and enterprise support status.