Spring v6 open source support ends June 2026

[Mark Waite]

The Spring Framework Versions wiki page states:

Supported versions:

• 7.0.x is the start of a new framework generation and the current production line (November 2025), to be followed up by the 7.1.x feature branch (November 2026).

• 6.2.x is the final feature branch of the 6th generation. Open source support ends in June 2026; commercial long-term support options are available.

• 5.3.x was the final feature branch of the 5th generation. Open source support ended in August 2024; commercial long-term support options remain available.

Since open source support for Spring Framework 6.2.x ends in June 2026, I think Jenkins needs to upgrade to Spring Framework 7 and Spring Security 7 before the end of June 2026.

I've successfully tested a draft pull request that combines the two Spring v7 pull requests (Spring Framework v7 and Spring Security v7) with the plugin BOM and the acceptance test harness..Minor changes were needed for two automated tests because Spring Security v7 added features that could simplify a multi-factor authentication implementation.  Minor changes were needed for the Jenkins PasswordHashEncoder class because Spring Security v7 made the encoder method final and we were extending it to provide a better error message.

The key question for me is: "Should we include Spring Framework v7 and Spring Security v7 in the April 2026 LTS baseline or the July 2026 LTS baseline?".  The April 2026 LTS baseline will be chosen on March 4, 2026 and released on April 15, 2026.  The July 2026 LTS baseline will be chosen on May 27, 2026 and released on July 8, 2026.

April 2026 LTS Baseline

• Jenkins always runs a supported open source Spring version.  There is a several month overlap between the Spring v6 end of support and Jenkins' use of Spring v7
• Merging to the Jenkins weekly branch must happen this week or early next week to be included in the April 2026 LTS baseline. However, that only gives us 6-8 weeks of Spring v7 in weekly before its release in the April 2026 LTS baseline
• Because I will be unavailable for two weeks starting February 24, 2026, others will need to handle issues with Spring v7 in Jenkins before the April LTS baseline selection.
• CloudBees has less time to run its automated tests on Jenkins with Spring v7

July 2026 LTS Baseline

• Jenkins will have a brief period (July 1 - July 8, 2026) where the most recent LTS release uses an unsupported open source Spring version
• Merging to the Jenkins weekly branch must wait until after the April LTS baseline. This gives us as much as 12 weeks of Spring v7 in Jenkins weekly before its release in the July 2026 LTS baseline
• CloudBees has much more time to run its automated tests on Jenkins with Spring v7

Which is the preferred choice?

If the April 2026 LTS baseline is chosen, who will handle issue reports for Spring v7 while I'm unavailable?

Thanks,

Mark Waite

[Daniel Beck]

> On 22. Feb 2026, at 14:06, Mark Waite <mark.ea...@gmail.com> wrote:
>
> • Jenkins will have a brief period (July 1 - July 8, 2026) where the most recent LTS release uses an unsupported open source Spring version

I don't expect that to be a problem given our release cadence/timeline to address non-critical issues. And if it's critical, we can always publish the new release early. The RC will have been around for a week by July 1.

[Jesse Glick]

On Sun, Feb 22, 2026 at 8:07 AM Mark Waite <mark.ea...@gmail.com> wrote:

• CloudBees has less time to run its automated tests on Jenkins with Spring v7

I just ran them. Everything passed except a few tests which were surprised by the `FACTOR_PASSWORD` authority you already found.

CONFIDENTIALITY NOTICE: This email and any attachments contain confidential and proprietary information of CloudBees intended only for the named recipient(s). Unauthorized use or distribution is prohibited. If you received this in error, please notify the sender and delete this email.

[Mark Waite]

On Sun, Feb 22, 2026 at 8:40 AM Daniel Beck wrote:

> On 22. Feb 2026, at 14:06, Mark Waite wrote:
>
>     • Jenkins will have a brief period (July 1 - July 8, 2026) where the most recent LTS release uses an unsupported open source Spring version

I don't expect that to be a problem given our release cadence/timeline to address non-critical issues. And if it's critical, we can always publish the new release early. The RC will have been around for a week by July 1.

I agree.  I think upgrading to Spring v7 in the July LTS baseline is the best choice.

Mark Waite

[Mark Waite]

On Mon, Feb 23, 2026 at 2:59 PM Jesse Glick wrote:

On Sun, Feb 22, 2026 at 8:07 AM Mark Waite wrote:

• CloudBees has less time to run its automated tests on Jenkins with Spring v7

I just ran them. Everything passed except a few tests which were surprised by the `FACTOR_PASSWORD` authority you already found.

That is great news.  Thanks very much!

I think that we should also consider upgrading to Jakarta Servlet API 6.1.0 as part of the upgrade to Spring v7 because the Spring v7 announcement blog post notes that they use Jakarta Servlet 6.1.0.

I'll explore that more deeply after I return from vacation.

Mark Waite

[Jenkins Developers]

The plugin BOM tests pass, the acceptance test harness tests pass, and tests pass with 39 other plugins from the repositories of the top 250 most popular plugins.

I've marked the two pull requests (Spring Framework v7 and Spring Security v7) as "ready for merge".  Unless objections are raised, they will be merged after the security release is delivered next week.

I have not yet explored an upgrade to Jakarta Servlet API 6.1.0.  I think that can be separated from the Spring v7 upgrade.

Mark Waite

[Mark Waite]

On Thu, Mar 12, 2026 at 5:00 PM Mark Waite wrote:

 

The plugin BOM tests pass, the acceptance test harness tests pass, and tests pass with 39 other plugins from the repositories of the top 250 most popular plugins.

I've marked the two pull requests (Spring Framework v7 and Spring Security v7) as "ready for merge".  Unless objections are raised, they will be merged after the security release is delivered next week.

I have not yet explored an upgrade to Jakarta Servlet API 6.1.0.  I think that can be separated from the Spring v7 upgrade.

The Jakarta Servlet API 6.1.0 upgrade is beyond my abilities. 

Jakarta Servlet API 6.1.0 has removed the jakarta.servlet.http.HttpSessionContext class.  It was deprecated in the Java(tm) Servlet API 2.1 for security reasons.  Stapler uses HttpSessionContext through the HttpSessionContextWrapper with its toJakartaHttpSessionContext and fromJakartaHttpSessionContext methods.

What are the risks if we upgrade to Spring Security v7 and Spring Framework v7 without upgrading from the Jakarta Servlet API 5.0.0 to Jakarta Servlet API 6.1?

Mark Waite

[Daniel Beck]

> On 14. Mar 2026, at 15:52, Mark Waite <mark.ea...@gmail.com> wrote:
>
> Jakarta Servlet API 6.1.0 has removed the jakarta.servlet.http.HttpSessionContext class. It was deprecated in the Java(tm) Servlet API 2.1 for security reasons. Stapler uses HttpSessionContext through the HttpSessionContextWrapper with its toJakartaHttpSessionContext and fromJakartaHttpSessionContext methods.

That was added for compatibility during for the Jakarta migration. Might be entirely unused beyond API compatibility/completeness in HttpSessionWrapper. Yry to delete it, see what happens?

[Jesse Glick]

On Sat, Mar 14, 2026 at 8:09 PM Daniel Beck <m...@beckweb.net> wrote:

[HttpSessionContext] Might be entirely unused beyond API compatibility/completeness in HttpSessionWrapper.

 Indeed, I can find no usages. https://github.com/jenkinsci/jenkins/blob/659b4380bf1829fcb114665618a9c665e329d0e0/core/src/main/java/hudson/security/HttpSessionContextIntegrationFilter2.java#L43 (whatever that does) does not seem to refer to it. Just try deleting the wrapper.