[PROPOSAL] Long-term support versions

[andrross]

The OpenSearch Software Foundation (OSF) is working to establish official long-term support versions that provide updates to OpenSearch versions beyond what is currently supported by the OpenSearch Project. These versions will be supported by approved vendors as selected by the OSF. The TSC can help by defining a policy for these LTS versions, with two specific questions where guidance is needed:

• What is the minimum service level agreement that approved vendors must adhere to when producing LTS builds?
• Which versions will become LTS versions, for how long, and at what cadence?

[andrross]

As a strawman to spur discussion here, I can propose the following answers:

What is the minimum service level agreement?

Vendors must follow the OpenSSF best practice guideline of fixing medium and higher CVEs within 60 days.

Which versions will become LTS versions?

I think the important thing here is to establish LTS releases going forward, so I would suggest something like "the first release after March 1 of each year will be designated an LTS version and will be maintained for the next 18 months per the SLA above"

[msfroh]

I feel like the minimum SLA could be in line with what we provide for the previous major version, where we address CVEs and sufficiently major bugs.

We currently have 2.19 as "kind of" a long-term release, but we have no commitment to it once 4.0 is released. If we released major versions more frequently, the support window would be shorter. I like the idea of adding a time-based guarantee of support.

Edit: I see that our existing maintenance policy sets a minimum window of 12 months. Of course, with our current (less frequent) major releases, I imagine that 2.19 will be supported much longer than that (since we're almost there already), but without all the nice 3.x features. I like the idea that someone could use (say) 3.6.x in a production environment for an extended period and continue to get security and bug fixes.

[epugh]

Do we need a super strong policy about which versions? I wonder if we could craft the message about "We will announce LTS support based on market feedback on version adoption when the next major version is released?" So, when 4.0 comes out, we announce the 2.x LTS versions, based on which ones actually have lots of users (and maybe, which ones are easier to support?). I don't know that we can predict which versions of 3.x will have signficiant adoption.

I would guess, and would love to see some data, that in the 2.x line, 2.19 has less adoption than an earlier one.. Under the theory that those who continuellly update their 2.x version, will end up jumpitng to 3 and not need LTS. But that firm that pick 2.5 is just going to want 2.5 for forever (or however long LTS means).

[epugh]

Here is my stab at your two questions:

What is the minimum service level agreement that approved vendors must adhere to when producing LTS builds?

Within thirty days of a CVE being announced unless there are extenuating circumstances verified by OpenSearch Foundation?

Which versions will become LTS versions, for how long, and at what cadence?

On every major release, we designate the version that is moving into LTS based on our assessment of need. We continue that support for at least ten years unless OpenSearch Foundation decides it's no longer save. The cadence remains "per major versino".

[andrross]

Thanks @msfroh and @epugh.

Just to refine a bit on the SLA portion, I think we need to define severity level for CVEs that must be fixed. And at least initially I think we should stick with the same time frame that we promise for the project's regular releases (60 days). So combining feedback from Eric and Michael, we get:

LTS releases must fix medium and higher CVEs within 60 days of public disclosure, unless there are extenuating circumstances verified by the OpenSearch Software Foundation. Major bugs as identified by the OpenSearch Software Foundation must also be fixed within 60 days of notification.

As to the version policy, my understanding is that one of the motivations for these LTS versions is that some enterprises are blocked from adopting OpenSearch due to the lack of an official LTS release with a sufficiently long support guarantee. So this is less of adding LTS support to an existing 2.x version and more of establishing an LTS policy going forward that is compatible with these enterprise requirements.

[epugh]

I didn't know about the LTS thing being an issue, though I can of course see that! Would that mean those enterprises would be starting in the 3x line, and are there anything we would do differently in 3x to facilitate that LTS guarantee? Also, if that is drivign it, then I might suggest that the "sufficiently long support guarantee" then implies we should pick whatever industry standard number meets that goal!

[andrross]

Would that mean those enterprises would be starting in the 3x line, and are there anything we would do differently in 3x to facilitate that LTS guarantee?

@epugh The difference would be that this LTS policy would support a particular 3.x version for some period of time (e.g. 18 months). Today we only support the latest 3.x release for 8 weeks, because after 8 weeks it is replaced by the next minor version release. Some organizations are happy to keep updating to the latest, but the LTS policy would provide an alternative of being able to stay with a particular version for a longer period of time.

[blewis-ai]

All great feedback and process. Users like Ericsson and Colins Aerospace require a specific time period (they specifically mentioned 18 months as ideal). With that cadence, we likely need to start with the last version of 2 (as discussed) and put a mark in the sand with 3.5/6. Thecadence of 1 LTS version per 12 month cadence may be sufficient. It is on the vendor to support it as per our SLA and do like the above ideas regarding the minimum SLA as per Andrew's input.

[andrross]

Thanks @blewis-ai. I propose this policy:

LTS releases must fix medium and higher CVEs within 60 days of public disclosure, unless there are extenuating circumstances verified by the OpenSearch Software Foundation. Major bugs as identified by the OpenSearch Software Foundation must also be fixed within 60 days of notification.

Every supported major version of OpenSearch will have at least one designated LTS version with support for at least 18 months. Additional versions can be designated LTS by the OpenSearch Software Foundation if appropriate.

With this policy, we can designate OpenSearch 3.6 (to be released in early April) as the LTS version for OpenSearch 3. The project itself already supports OpenSearch 2.19 for a minimum of 12 months, so a vendor would only be required to extend the life of that version if the project dropped support before the 18 month mark. It also gives leeway to add more LTS versions in the 3.x line if we do not release OpenSearch 4 anytime soon.

[blewis-ai]

Sounds great Andrew! And everything is agreed. I will get this formalized with the vendors, announced, and keep you in the loop. Best, Bianca

…

On Mon, Mar 9, 2026 at 4:27 PM Andrew Ross ***@***.***> wrote: *andrross* left a comment (opensearch-project/technical-steering#86) <#86 (comment)> Thanks @blewis-ai <https://github.com/blewis-ai>. I propose this policy: LTS releases must fix medium and higher CVEs within 60 days of public disclosure, unless there are extenuating circumstances verified by the OpenSearch Software Foundation. Major bugs as identified by the OpenSearch Software Foundation must also be fixed within 60 days of notification. Every supported major version of OpenSearch will have at least one designated LTS version with support for at least 18 months. Additional versions can be designated LTS by the OpenSearch Software Foundation if appropriate. With this policy, we can designate OpenSearch 3.6 (to be released in early April) as the LTS version for OpenSearch 3. The project itself already supports OpenSearch 2.19 for a minimum of 12 months, so a vendor would only be required to extend the life of that version if the project dropped support before the 18 month mark. It also gives leeway to add more LTS versions in the 3.x line if we do not release OpenSearch 4 anytime soon. — Reply to this email directly, view it on GitHub <#86 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B7MWTKXB2Z5Z54MC6O7BO5D4P5HO5AVCNFSM6AAAAACVYE6ZTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMRXGU4DONZUGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[blewis-ai]

Agreed - we will formalize this policy.