DR-000043 - Support period
Submitted Date | 2025-08-28 |
Approved Date | TC: Oct 20, 2025 https://folio-org.atlassian.net/wiki/spaces/TC/pages/1295417345 |
Status | ACCEPTED |
Impact | MEDIUM |
Decision
For a FOLIO flower release the support period starts with the general availability (GA).
Before development for a flower release starts Technical Council determines the end date of the support period and the officially supported technologies.
During the support period FOLIO provides critical service patches (CSPs), for details see Critical Service Patch Process.
Ramsons support period ends 2025-12-31. Security team will publish triage results of Ramsons security issues until 2026-03-31, no fixes will be provided.
For Ramsons the Release Management Stakeholders group may approve priority 1 functional fixes after the end of the official Ramsons support period. This cannot be declared officially supported because of potential security issues.
Sunflower support period ends 2026-06-30.
Overrides/Supersedes
PC Supports long-term release and regular release recommendations
LTS recommendations (Long Term Support) [also contains the regular release recommendations]
This decision made in January 2022 effectively says that the support period for a flower release X lasts until flower release X+2 is officially released (GA – general availability).
Extending Okapi Ramsons support until 31 March 2026
(https://folio-org.atlassian.net/wiki/spaces/CC/pages/939393089)
RFC
n/a
Stakeholders
Implementers, Sysops, Release Management Stakeholders (RMS) Group
Contributors
@Julian Ladisch
Approvers
TC: lazy consensus: Jenn Colt, Shelley Doljack, Florian Gleixner, Olamide Kolawole, Julian Ladisch, Craig McNally, Wayne Schneider
PC: Vote: @Charlotte Whitt , @Lisa McColl , @Thomas Trutt , @Tod Olson , @Martin Scholz , @Jennifer Eustis , @Alexis Manheim , @Autumn Faulkner
Background/Context
The majority of FOLIO back-end modules are based on Spring.
LTS recommendations declares unfinished software to be the "current release" which is wrong or at least confusing.
In August 2025 the release date for Trillium has been moved from November 2025 to Spring 2026. Using the LTS recommendations (link above) this indirectly moves the end of support for Ramsons from November 2025 to Spring 2026, this exceeds the Spring Boot 3.4 support period and poses security risks.
Constraints
More than 30 modules use the Spring framework (see BE framework column on https://folio-org.atlassian.net/wiki/spaces/REL/pages/5210256).
In May and in November a new major version of Spring Boot and a new major version of Spring Framework is published (GA) and the open source software (OSS) support ends after 13 months:
Longer commercial support for Spring is available but requires a paid license per cpu that is way too expensive for FOLIO hosters.
To be able to migrate to the next major Spring version early, developers use snapshot, milestone or release candidate versions. For details see Migration to Spring Boot 4.0 (Trillium).
Using a software library after the end of support poses a security risk because security bugs may not get published, may not get fixed, and/or fixes may not get published.
For a supported library version a.b.x a fix is published as a patch version a.b.y that only contains fixes. A patch version can easily been applied and requires only basic testing.
For an unsupported library version no patch version gets published, instead you need to migrate to the next minor or major version which requires much more development effort and requires much more testing. Forking and trying to patch the unsupported version also requires significant development and testing effort.
Go language has a support period that doesn’t fit with Spring’s and FOLIO’s release cycle, a CSP with minor or major version bump of Go is needed during the FOLIO support period. We know that bumping Go to a new minor or major version is much easier than bumping Spring to the next minor or major version. Therefore TC allows Go modules with a Go version that has shorter support period than the FOLIO flower release. The number of Go modules is small.
Liability for deliberate and grossly negligent acts when using unsupported software libraries, see Apache License 2.0 liability clause.
Article 4 paragraph 3 of EU Cyber Resilience Act requires that unfinished software must be marked to be for testing purposes only.
Assumptions
Spring keeps their release and support schedule for OSS.
There will be Okapi support for the Sunflower release, an announcement about this is expected soon.
Rationale
TC’s goal is a flower release support period of about twelve months. It is not the support period of the technology with the smallest support period. But the number of technologies that go out of support during the flower release support period should be limited to reduce the security risks that arise from technologies that are out of support.
When TC determines the end of support date and the officially supported technologies it consults all relevant stakeholders, including release manager stakeholder group and development teams.
Currently TC decides on the officially supported technologies for a flower release, the support period is already an important part of the decision process. At that time TC should also decide on the FOLIO flower release support end.
FOLIO Security Team triages all potential vulnerabilities. Often FOLIO is not affected, see resolution “Won’t do” in the Security Jira: https://folio-org.atlassian.net/jira/core/projects/SECURITY/issues?jql=project%20%3D%20%22SECURITY%22%20ORDER%20BY%20created%20DESChttps://folio-org.atlassian.net/jira/core/projects/SECURITY/issues?jql=project%20%3D%20%22SECURITY%22%20ORDER%20BY%20created%20DESC. The FOLIO Security team tries to find a workaround (mitigate or circumvent the vulnerability), however, a workaround is not possible in all cases. This decision record addresses the cases where no workaround is possible and the vulnerability must be fixed in the software library.
The wrong, or at least confusing, wording about the "current release" (see LTS recommendations) should be dropped. Instead the unfinished release in development should be named the “next” or “unfinished” release, it is for testing only and should not be mentioned in the support policy.
For Ramsons end of support date the end of OSS support for Spring Boot 3.4 is used; this avoids back-ports from Spring Boot 3.5 which might be difficult or impossible in case a new security issue for Spring Boot gets published.
For Ramsons the FOLIO security team extends Ramsons security issue triage to end of March 2026. Triage will be on a best effort basis only. No fixes will be provided. This means that the Ramsons CSP support (= patches) ends 2025-12-31 but institutions that continue running Ramsons can better evaluate their risk. If there's a critical issue they need to shut down their Ramsons FOLIO installation.
For Ramsons the Release Management Stakeholders group may approve priority 1 functional fixes after the end of the official Ramsons support period [this sentence should be refined by PC/CC (funding, end date, …)]. This cannot be declared officially supported because of potential security issues.
For Sunflower end of support date the end of OSS support for Spring Boot 3.5 is used; this avoids back-ports from Spring Boot 4.0 which might be difficult or impossible in case a new security issue for Spring Boot gets published.
The Trillium release date has not been determined yet. TC will update the Trillium Officially Supported Technologies to adopt for the new release date. The Trillium end of support date will likely be the end of OSS support for Spring Boot; this avoids back-ports from more recent Spring Boot minor versions which might be difficult or impossible in case a new security issue for Spring Boot gets published. The Trillium end of support date will likely be 2026-12-31 if Trillium uses Spring Boot 4.0, it will likely be 2027-06-30 if Trillium uses Spring Boot 4.1.
When the decision about the support period policy was made in January 2022 there were three flower releases per year resulting in a support period of about 8 months. Since 2023 there are only two flower releases per year resulting in a support period of about 12 months. The Trillium release is the first flower release where the planned gap to the previous release is significantly longer than 6 months. This requires a new support period policy for security reasons.
The old support policy results in a support period that is longer if there a fewer flower releases per year: 3 flower releases per year result in ~ 8 months of support, 2 flower releases per year result in ~ 12 months of support.
If there are 3 flower releases per year the new support policy results in a longer support period than the old policy (from ~8 months to ~9-~13 months).
Assuming there are 2 flower releases per year: If the release is planned for May, June, November or December the new support policy results in a longer support period than the old policy, otherwise in a shorter support period. This is because Spring Boot releases a new version in May and November with a support period of ~13 months.
If the planned time between flower releases is 9 months or longer then the new support policy results in a shorter support period than the old policy.
Implications
Pros
Reduces security and liability risks.
Fixed end of support dates allow better migration planning.
The Ramsons support period is extended by about one month based on the previously published Trillium release date in November 2025.
Institutions are free to (and some institutions already do) run a flower release after the support period has ended – at their own risk. FOLIO doesn’t raise false expectations.
If two consecutive flower releases get ready in less than 6 months there will be a time where three flower releases are supported at the same time.
Cons
Migration from Ramsons to Sunflower by end of 2025 is a tight schedule: If migrating from Okapi-Ramsons to Eureka-Sunflower it requires tooling that is still work in progress, if migrating from Okapi-Ramsons to Okapi-Sunflower there’s risk because Okapi-Sunflower bugfest is not available yet.
The current moving end of support date makes hosters hope that it moves to a later date.
If consecutive flower releases take more than six months there will be a time where only a single flower release is supported.
Other Related Resources