Spring Boot Support Lifecycle & Release History

How Does Spring Boot Handle Version Support and EOL?

Spring Boot is an open-source Java framework maintained by Broadcom (formerly VMware Tanzu) that provides opinionated auto-configuration and production-ready tooling on top of Spring Framework. Each minor version receives at least 12 months of OSS support, and each major version line is covered for at least 3 years -- provided you stay on a supported minor within that major.

Support runs in two phases. During OSS support, the team publishes patch releases with bug fixes and security updates freely to Maven Central. Once that window closes, a commercial enterprise support phase begins for qualifying long-term versions, covering critical and security-only fixes under a Tanzu Spring subscription. The final minor of each major line -- for example, the last 2.x or 3.x minor -- typically receives the longest enterprise window. Refer to the release table above for exact End of OSS support and End of enterprise support dates per branch.

Because Spring Boot's managed BOM controls the versions of Spring Framework, Spring Security, Spring Data, and dozens of starters, the Boot minor version is the single most important lifecycle marker for your entire Spring stack. When a Boot minor goes EOL, so does the version of every portfolio project it pins.

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

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

Running an unsupported Spring Boot version means CVEs in Boot's auto-configuration layer, embedded Tomcat or Netty, and any starter dependency it manages will not receive patches -- leaving known attack surfaces permanently open.

Spring Boot's auto-configuration is what makes it convenient, but it also means Boot owns dozens of dependency versions on your behalf. Once a Boot minor goes EOL, those pinned versions freeze. Security patches released by Jackson, Netty, Reactor, or Hibernate are no longer incorporated into your BOM, even if the library itself is still actively maintained upstream.

Actuator endpoints, which many teams expose internally for health checks and metrics, are a frequent target in CVE disclosures. A known vulnerability in an EOL Boot version's Actuator layer is documented publicly, and scanning tools used in attack automation routinely check for it.

Starter and ecosystem drift is the other long-term cost. Spring AI, Spring Authorization Server, and third-party starters all declare minimum Boot version requirements. Staying on an EOL Boot minor progressively narrows which ecosystem libraries you can adopt without forking or patching BOM declarations yourself.

What Happens After Spring Boot Reaches EOL?

After a Spring Boot version reaches full End of Life, all official maintenance stops -- no patch releases, no security updates, no changes of any kind from the Spring team for that branch.

Your existing applications will continue to run on the last published artifact. However, any CVEs disclosed after that point have no upstream fix for the EOL branch, and the complete dependency graph that Boot's BOM manages also stops receiving updates through that channel.

The enterprise support window -- visible in the End of enterprise support column of the release table above -- is the last available coverage before complete EOL. During that window, teams on a Tanzu Spring subscription receive critical and security-only patches without being required to migrate immediately. Once the enterprise window closes, no patch source of any kind remains.

Migration Direction

The standard migration path is to target the current stable Boot minor and let the BOM resolve the updated Framework, Security, and Data versions transitively. For major version jumps -- particularly moving to the 3.x line, which replaced the javax namespace with jakarta -- the Spring team publishes a dedicated migration guide covering configuration property renames, changed auto-configuration keys, and API removals. In practice, migrating one minor at a time and running the full test suite between each step produces significantly fewer surprises than multi-version jumps.

Tracking and Monitoring Spring Boot EOL Dates

Effective tracking starts with knowing the Boot minor version in every service -- not just what your pom.xml declares, but what each deployed artifact actually resolved at build time.

Check the End of OSS support column in the release table above and flag any branch within nine to twelve months of that date. That window is the practical minimum for a Boot minor upgrade across a multi-service architecture when you factor in dependency review, configuration testing, and staged rollout. Setting a reminder at the nine-month mark keeps the migration in planned sprint work rather than emergency response.

Tools like Dependabot or mvn versions:display-dependency-updates will notify you of available patch releases, but they do not report EOL status. That check remains manual against the release table. Many teams add a Boot version and EOL date field to their service catalog or internal developer portal to make cross-service visibility easier.

How To Check Your Spring Boot Version

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

Maven -- check declared Spring Boot parent version

mvn help:evaluate -Dexpression=spring-boot.version -q -DforceStdout

Gradle

./gradlew dependencyInsight --dependency spring-boot-autoconfigure

At runtime via Actuator

If the info actuator endpoint is enabled and spring-boot-actuator-autoconfigure is on the classpath, Boot exposes its own version in the info response automatically. You can also read it programmatically:

import org.springframework.boot.SpringBootVersion;

System.out.println("Spring Boot version: " + SpringBootVersion.getVersion());

From the running JAR

java -jar your-app.jar --version

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