On September 21, 2026 the Spring team announced a significant change to how the whole portfolio ships. Instead of releases trickling out over a two-week window, Spring projects will now release together on a single day each month, the Thursday after the third Monday, which the team calls "Patch Thursday". A few days later, Spring Boot 4.2.0-M2 shipped on September 25 as part of a milestone-only train. In this post I look at why the change happened, what it means for teams running Spring Boot in production, and how I'm adjusting my own upgrade pipeline.
Why Spring Changed Its Release Model
The announcement is candid about the motivation: security. The team reported averaging nearly 80 community-provided security reports a month since March, and more than 160 CVEs addressed recently. With AI tools making vulnerability discovery and exploitation faster, a staggered release window means a fix in one project can wait days for the rest of the portfolio to catch up.
Releasing everything on one predictable day fixes two problems:
- Coordination: Spring Framework, Spring Security, Spring Data and Spring Boot patches land together, so a Boot patch picks up the matching dependency fixes immediately.
- Planning: security and platform teams know exactly when to expect patches, the same way many teams already plan around Microsoft's Patch Tuesday.
The first regular patch train under the new model is scheduled for October 22, 2026. The team has also redesigned the security advisories page so you can filter CVEs by ID, severity and project.
What This Means for Your Team
If you currently upgrade Spring Boot "whenever someone notices", Patch Thursday is a good moment to make it a routine. My recommendation:
- Put a recurring slot on the calendar for the Friday after each Patch Thursday.
- Automate the version bump pull request so it is already waiting.
- Let CI prove the upgrade, then ship.
Automating the bump with Dependabot
Dependabot can group all Spring artifacts into a single pull request and run on a weekly schedule anchored to Thursday:
# .github/dependabot.yml
version: 2
updates:
- package-ecosystem: "maven"
directory: "/"
schedule:
interval: "weekly"
day: "thursday"
time: "18:00"
groups:
spring:
patterns:
- "org.springframework*"
open-pull-requests-limit: 5
For Gradle projects, change package-ecosystem to "gradle". Grouping matters: upgrading spring-boot-starter-parent alone while a separately pinned Spring library lags behind is exactly the kind of mismatch the new coordinated train is meant to avoid.
Stop pinning versions the BOM already manages
The Spring Boot parent (or BOM) manages versions for the Spring portfolio and many third-party libraries. Every explicit <version> you add for a managed dependency is a place where a Patch Thursday fix can silently be skipped:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>4.1.x</version> <!-- the only Spring version you should bump -->
</parent>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
<!-- no <version>: managed by the parent -->
</dependency>
</dependencies>
Run ./mvnw dependency:tree (or ./gradlew dependencies) after the bump to confirm nothing is still pulling an older Spring artifact.
Verify what is actually running
After deployment, confirm the new version really reached production. With Actuator's info endpoint and build info enabled, it's a one-liner:
curl -s https://api.example.com/actuator/info | jq '.build'
Enable build info in Maven with the build-info goal of spring-boot-maven-plugin, or springBoot { buildInfo() } in Gradle.
A First Look at Spring Boot 4.2.0-M2
Spring Boot 4.2 is still in milestones, and M2 includes 141 enhancements, documentation improvements, dependency upgrades and bug fixes. Two highlights from the announcement:
- SSL bundle support for LDAP, including LDAPS support for the embedded LDAP server. If you already use SSL bundles for web servers or data stores, LDAP now plugs into the same mechanism.
- OpenTelemetry improvements: support for OpenTelemetry's semantic conventions, plus common OTLP endpoint, header and compression configuration, so you no longer need to repeat the same collector settings per signal.
SSL bundles have been around since Spring Boot 3.1, and defining one looks like this:
spring:
ssl:
bundle:
jks:
corp-ldap:
truststore:
location: "classpath:ldap-truststore.p12"
password: "${LDAP_TRUSTSTORE_PASSWORD}"
type: "PKCS12"
The exact property that points LDAP at a bundle is documented in the 4.2 release notes; check them rather than guessing, since milestone property names can still change before GA.
To try the milestone in a side branch, add the Spring milestone repository:
<repositories>
<repository>
<id>spring-milestones</id>
<url>https://repo.spring.io/milestone</url>
</repository>
</repositories>
Keep milestones out of production. Use them to catch breaking changes early and file issues while there's still time to fix them.
Use the properties migrator when jumping versions
When moving across minor versions, add spring-boot-properties-migrator temporarily. It reports renamed or removed configuration keys at startup:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-properties-migrator</artifactId>
<scope>runtime</scope>
</dependency>
Remove it once the warnings are gone.
Key Takeaways
- Spring now ships the entire portfolio together on "Patch Thursday", the Thursday after the third Monday of each month.
- The first regular train under the new model is October 22, 2026.
- Group Spring dependencies in Dependabot or Renovate and schedule them around Thursday.
- Let the Spring Boot BOM manage versions; explicit pins are where patches get missed.
- Spring Boot 4.2.0-M2 adds SSL bundle support for LDAP and better OpenTelemetry/OTLP configuration. Try it on a branch, not in production.