[PROPOSAL] Finalize 2024 release schedule for OpenSearch

[bbarani]

Introduction:

OpenSearch follows semver for versioning, which means we only release breaking changes in major versions. For our minor and patch releases we follow release window model, where we release around 6 weeks and the schedule is published published on OpenSearch.org at the beginning of the year.

Currently we are building and releasing minor, patch releases for 2.x and patch release for 1.x line. For 2.x, we have planned OpenSearch releases till 2.12.0 version but we haven’t planned any additional releases for 2024 yet.

We would like to get your feedback on this 2024 release schedule proposal to finalize the options before updating the OpenSearch release calendar.

Please provide your feedback and recommendation by commenting on this issue by Feb 15 2024 in order for us to update the 2024 release calendar in timely manner.

We have come up with 2 possible options but we welcome any additional options from the community.

Option 1:

Keep supporting 2.x minor version and 1.x patch version in 2024 and plan for 3.0 release in 2025.

Release Number	First RC Generated (release window opens)	Latest Possible Release Date (release window closes)
1.3.15	Feb 27 2024	March 05 2024
2.13.0	March 19 2024	April 2 2024
1.3.16	April 16 2024	April 23 2024
2.14.0	April 30 2024	May 14 2024
1.3.17	May 28 2024	June 06 2024
2.15.0	June 10 2024	June 25 2024
1.3.18	July 09 2024	July 16 2024
2.16.0	July 23 2024	August 06 2024
1.3.19	Aug 20 2024	August 27 2024
2.17.0	September 03 2024	September 17 2024
2.18.0	October 22 2024	November 05 2024
1.3.20	December 03 2024	December 10 2024
2.19.0	January 28 2025	Feb 11 2025

Option 2:

Keep supporting 2.x minor version and 1.x patch version in 2024 but skip few 2.x version in 2024 to prioritize 3.x release. We will need to support 1.x, 2.x and 3.x versions in 2024 until 3.0 GA version is released in 2025.

Release Number	First RC Generated (release window opens)	Latest Possible Release Date (release window closes)
1.3.15	Feb 27 2024	March 05 2024
2.13.0	March 19 2024	April 2 2024
1.3.16	April 16 2024	April 23 2024
2.14.0	April 30 2024	May 14 2024
1.3.17	May 28 2024	June 06 2024
2.15.0	June 10 2024	June 25 2024
1.3.18	July 09 2024	July 16 2024
2.16.0	July 23 2024	August 06 2024
1.3.19	Aug 20 2024	August 27 2024
2.17.0	September 03 2024	September 17 2024
3.0.0 (RC1)	October 28 2024	November 19 2024
1.3.20	December 03 2024	December 10 2024
3.00 (GA)	January 28 2025	Feb 18 2025

Breaking changes planned for 3.0.0 release:

OpenSearch:

• [RFC] Protobuf in OpenSearch OpenSearch#6844
• [FEATURE] Update to Apache Lucene 10 for 3.0.0 OpenSearch#11415
• [PROPOSAL] Set OpenSearch 3.0.0 baseline JDK version to JDK-21 OpenSearch#10745
• [META] Breaking changes in 3.0 OpenSearch#3351
• [RFC] Replace Java Security Manager (JSM) OpenSearch#1687
• [RFC] Jigsaw integration OpenSearch#1588
• Support for HTTP/2 (server-side) OpenSearch#3651
  More to come....

Possible to introduce in 2.x line in backward compatible manner

• Move Job Scheduler plugin to core (modules) job-scheduler#147
• [RFC] Admission Control mechanism for Cluster Manager APIs OpenSearch#7520

OpenSearch dashboards:

• Stop bundling node.js in distribution
• [RFC] Clickjacking Mitigation OpenSearch-Dashboards#5639
  More to come....

Frequently asked questions (FAQ):

How long will the 1.x version be actively supported?

We will continue to release patch versions for 1.x until the GA release of 3.0 version is released as mentioned on release schedule page. 1.x version will become end of life (EOL) once the GA release of 3.0 version is released.

When will 2.x version go in to maintenance mode?

Minor and patch releases for 2.x version will be supported until GA version of 3.0 is released. 2.x line will go in to maintenance mode ( i.e. only patch version will be released) once GA version of 3.0 is released.

Is there a plan to release 3.0 version in 2024?

The plan to release OpenSearch 3.0 version in 2024 is not yet finalized. Major versions will include breaking changes hence we will release release candidate (RC) version followed by GA release for 3.0 version. We will work with the community to take the decision based on the finalized outcome of options listed on this issue.

Why do we need to release a new major (3.0.0) version?

We have documented few breaking changes that are not compatible with 2.x versions but beneficial to the OpenSearch community in this issue. OpenSearch follows SemVar versioning and as per their guidelines, we can include the breaking changes in a MAJOR version (3.0) only.

What versions of OpenSearch will be actively supported post the release of 3.0 GA version?

We will support the patch releases for 2.x versions and minor, patch releases for 3.x versions post the release of 3.0 GA version.

How to provide the feedback or suggestions?

Please provide your feedback with your preferred option by commenting on this issue. Feel free to add any other breaking changes (not listed on this issue) that would warrant a major release (3.0) in the comment as well.

We welcome any additional feedback from the community!!!

[ZilongX]

Big thanks @bbarani for putting together this great detailed release proposal !!

First thing first, my vote goes to Option 2 :) (just can't wait for the rolling out of 3.0)

Yet meanwhile I do understand there could be a large load of action items involved just to support 3.0, let alone supporting 1.x and 2.x at the same time. So maybe we could take a bolder move to skip more releases in the 1.x and 2.x line just to ensure the release of 3.0 in late2024/early2025 (definitely don't want to skip any releases.. if we have the super power lol)

IMHO, currently the 1.x release line mainly focuses on the security fix (CVE fixes precisely) and any reported critical bugs fix which should come with minimum load of code changes, also support of 1.x will reach an end once 3.0 goes live anyway, so skipping one more 1.x release say 1.3.20 won't bring in much troubles.

On the 2.x release line, instead of skipping maybe postponing would be more accurate, where maybe we just reschedule the release of 2.17.0, from September 17 2024 to sometime in 2025, where 3.0 is already GAed and 2.x continues to fall within the support window, yet like the 1.x line today, mainly with security and bug fixes but major feature development work will be shifted to 3.x and new main (targeting 4.0)

It would gives us more time, say after release of 1.3.19 on August 27 2024, we just fully focus on the release of 3.0, and the stretch goal or the existing goal would be to release 3.0 as soon as possible :)

[seraphjiang]

One observation: the intervals(days) between minor/major versions of 2.x/3.0 don't seem to be even. Just curious if there are any special considerations.

[reta]

@bbarani a few more to 3.0.0, my concern is Apache Lucene 10 (no date AFAIK):

• [FEATURE] Update to Apache Lucene 10 for 3.0.0 OpenSearch#11415
• [PROPOSAL] Set OpenSearch 3.0.0 baseline JDK version to JDK-21 OpenSearch#10745
• [META] Breaking changes in 3.0 OpenSearch#3351

[stephen-crawford]

While the prospect of a 3.0 release is very exciting, I vote option 1 and want to highlight some of the reasons for others' consideration.

1. Releasing 3.0 puts the project at risk for significant slippage

As shared in Barani's awesome summary, a move to 3.0 in 2024 does not mean we drop 1.x in 2024. Instead we will be increasing the maintenance load (probably doubling it realistically--I assume 3.0 will require at least as much work as 2.x). This means repos will need to dedicate even more of their limited time to managing releases and making sure things are ready to ship. As seen with the 2.12 release, this is no small task; if we have to shift our releases already, how can we commit to delivering a high quality project when we add even more load on contributors?

2. Foundation first

As we all know a leadership committee was formed with various stakeholders from around the project. This committee is in the process of determining how to move OpenSearch into a foundation such as Apache or Linux. I suspect any movement will require at least some effort from the maintainers of the project. It seems unlikely that the move will be completely "clean" or just a change of regulations. Maintainers will likely have to be involved in some efforts to refactor or restructure things to meet new requirements. Trying to do this while releasing 3.0 seems risky.

3. More support of breaking changes

My final point is that it seems like some of the proposed breaking changes have pretty minimal input from the community. For instance, the issue focusing on admission control has been open since May 2023, and has no comments or details. I don't think we should be driving the project based on abstracts or what-ifs. If we move to 3.0 I feel we need to have a concrete list of heavily requested and bought-in changes which the community has actively discussed. Whether this occurs during a community meeting or elsewhere, I would want to see more discourse around changes before we use them as justification for a 3.0.

(This is not saying that the Admission Control RFC is a bad idea or anything, just that there has not been much engagement or follow-up).

I don't know what number of breaking changes would justify a 3.0 or whether the magnitude of a change should make it worthwhile on its own (for instance the Lucene bump).

TL;DR: I vote for option 1 unless we can get safeguards in place to make sure we have sufficient community support, know the costs for each release, and are certain that a 3.0 release will not slow movement to a foundation.

[bbarani]

One observation: the intervals(days) between minor/major versions of 2.x/3.0 don't seem to be even. Just curious if there are any special considerations.

@seraphjiang Major versions usually require additional preparation time and release cycle time due to the sheer number of breaking changes, features, documentation, infrastructure setup, security review and extensive testing hence added some buffer for 3.0 versions.

[bbarani]

@bbarani a few more to 3.0.0, my concern is Apache Lucene 10 (no date AFAIK):

• [FEATURE] Explore the update route to Apache Lucene 10 for 3.0.0 OpenSearch#11415
• [PROPOSAL] Set OpenSearch 3.0.0 baseline JDK version to JDK-17 OpenSearch#10745
• [META] Breaking changes in 3.0 OpenSearch#3351

Added these items to the 3.0 breaking changes list on this issue. CC: @reta

[andrross]

Regarding potential breaking changes for 3.0, here are a couple more:

• [RFC] Replace Java Security Manager (JSM) OpenSearch#1687 To my knowledge no path forward has been settled upon here, but whatever we choose will likely be a breaking change
• [RFC] Jigsaw integration OpenSearch#1588 Adopting JPMS would be great and would be a breaking change

[bbarani]

Regarding potential breaking changes for 3.0, here are a couple more:

• [RFC] Replace Java Security Manager (JSM) OpenSearch#1687 To my knowledge no path forward has been settled upon here, but whatever we choose will likely be a breaking change
• [RFC] Jigsaw integration OpenSearch#1588 Adopting JPMS would be great and would be a breaking change

Added these items to the 3.0 breaking changes list. CC: @andrross

[AESthetix256]

I am with @ZilongX on this one and would prefer Option 2.

In my org we prefer dealing with breaking changes sooner than later and in this case I think it would benefit the project in the long-run to focus development on 3.x a little earlier. I don't have any actual insight into the OpenSearch codebase since I am not a dev, but I have a gut feeling that possibly some work done on 2.x needs to be done twice for it to work with 3.x and if we could limit the changes required for 3.x this could speed up future development.

[dblock]

There's a significant amount of divergence in 3.x, and the cost of the gap will continue to compound. I vote for option 2.

[tianleh]

Add an OSD 3.0 breaking change opensearch-project/OpenSearch-Dashboards#5639

[Pallavi-AWS]

Can the teams tagged with breaking changes evaluate if the changes are indeed breaking or can be done in a backward compatible manner?

[elfisher]

While there are pros and cons to both options, I think option 1 is better since upgrading to a new major version requires significant work for everyone in the community. Some of these features in the list we can probably introduce in 2.x as optional (e.g., protobuf support)