IdPReleaseSchedule

Due to compression of Spring Framework support timelines, we need to map out future Shibiboleth Identity Provider releases with more precision and forward planning than in the past. To assist with community planning, this is the plan for handling the next few IdP releases. Notably the forthcoming SP V4 “hub” being implemented as IdP plugins will also be impacted by this, as will all the other plugins, so most of our software will be impacted by this plan over time.

The major versioning implicatons going forward are:

1. Our major releases are not as likely to be motivated by Java platform changes unless the Spring Framework or Jetty requires them, but any such change would still be done in a major update, as they have been. We are presently based on Java 17 and have no immediate plan to migrate to a newer version at this time.

2. Our major and minor releases can no longer be coupled to Spring Framework major and minor releases, as has been the common approach in the past. That is, we almost certainly will bump to new Spring minor releases in our patch releases and new Spring major releases in our minor releases, subject to testing to rule out deployer impact.

   1. The implication of this change is that deployers should take care to avoid significant use of native Spring APIs in their own scripts and extensions. This is relatively rare as it is, and if there are needs identified we can work to wrap the functionality involved where possible.

Release Schedule/Timelines

The EOL dates here are not in general estimates because they are derived from Spring’s published plan. Going forward, it’s expected that almost all of our releases will have to be sunsetting on their timeline, not any preferences of ours, and so will typically occur mid-year.

Thus, most of our non-security-driven releases should be expected in the Q4-Q1 window, with support ending about 18 months from release.

The Plan

1. We ship IdP V5.1.5 very shortly (August 2025) with Spring 6.2. Minimal if any impact is expected. No new features obviously.

2. We ship IdP V5.2.0 late in 2025 or early in 2026 on Spring 7.0, documenting any known impact. Existing feature work on the main branch now will be included plus some additional queued work, but no major API changes we may be entertaining. Plugins would be expected to continue to be pegged to V5.0.0 with the Jetty plugin being an exception, targeting V5.1.0 at this point when it’s ready.

   1. Corrolary: we need to carefully track and preserve any plans we have for changes for V6.0 so we don’t forget about them all, fixes for plugins for example.

3. We expect, but cannot, promise that we can extend the support timeline for IdP V5 by incorporating Spring 7.x updates. If that turns out to be a problem, we will have to adjust our plans and likely ship V6.0 much sooner instead of V5.2.

4. We plan on V6.0 somewhere in the 2026-2027 time frame. We would not expect major upgrade risk from that release in order to compress the support timeline for V5.

5. We will document a release schedule for 6.x follow on work once we have a better idea what Spring’s plans are for post-7.0 releases.

6. Rinse and repeat, but with the same general cadence if Spring maintains theirs.

Planning Inputs

Spring 6.1 (so far used by all IdP 5.1.x releases) lost support on Jun 30, 2025.

Spring 6.2 ends support on Jun 30, 2026. It appears to be a low impact update for us and we think it could be included in a patch release.

Spring 7.0 is expected in November, 2025 and ends support on Jun 30, 2027. It is relatively low impact so far but testing identified one issue that is best handled with an API change we don’t think is material to deployers, though it would need to be called out. It appears likely we could ship this with either a minor or major release based on other factors.

We do not know how many minor versions 7.x or indeed any of their major branches will have unless they have produced any commitments around that going forward we don’t know of. Spring 5 had 4 minors and Spring 6 had 3.

We have no way of knowing the timeline for Spring 8.0 or its requirements or impact, though it seems possible it could require a Java LTS version beyond 17.

Spring Web Flow Impact

Spring Web Flow remains officially supported, but is lacking in maintenance resources and could introduce unpredictable delays if compatibility changes for Spring Framework lag those releases. For example, we cannot know if Spring 7.0 might break SWF 3.0 right now and if it does they have committed to fix it but not on a specific schedule. Our own resources could potentially impact that schedule when it becomes a problem for us, but in general this is a risk with unknown impact.

That said, so far Spring 7.0 does not appear to break our tests, suggesting it may work with the current SWF version, and Spring’s versioning tends to be solid enough that this risk is primarily likely to occur around Spring’s major releases.

Plugin Impact

Our plugin story is still relatively “new”, but our limited history suggests that our own versioning religiosity allows our plugins to target a particular major version API and remain compatible through the life of that branch. This should extend to third-party plugins that stay confined to supported APIs and avoid significant direct Spring dependencies.

We expect plugins will continue to require some changes and new major versions to accompany our major releases, with the possible exception of some of the simpler ones like scripting support.

The SP hub plugins are too early in their development to be committal about them yet, but they will likely be closer in kind to the OIDC plugin family (and in fact one will depend on some of those), and so will also usually require revisions at major API breaks. While those plugins have their own configuration challenges, we would expect that upgrading the SP hub when required will be no more risky, and probably less so, than upgrading the IdP has been (when operating as an IdP).