[PROPOSAL] Release OpenSearch 3.0

[andrross]

In the nearly 3 years since we released OpenSearch 2.0 we have delivered significant features and innovations while adhering to semver. Now that Lucene 10 has been released, we should take this opportunity to release OpenSearch 3.0. We will update Lucene, make key changes to enable future modularity, remove legacy cruft, and establish a modern JDK baseline to unlock the latest language improvements and allow for compatibility with future JDKs.

Meta Issues

• OpenSearch: [META] Breaking changes in 3.0 OpenSearch#3351
• Dashboards: @ashwin-pc / @AMoo-Miki to create a tracking issue in OpenSearch-Dashboards
• Clients: [PROPOSAL] Support OpenSearch 3.0 opensearch-clients#78

Timeline

This proposal is to tentatively target 2.19 (to be released by February 19, 2025) as the last minor version of the 2.x line. That would result in a 3.0 release around April 2025. A more specific timeline, including the rest of 2025, can be found here: #252

FAQ

How Can I Help?

Please provide any feedback you have! For project-wide concerns like timeline and maintenance policies please comment directly on this issue. If you have suggestions about changes to a specific component, feel free to comment on an issue (or open a new one) in the corresponding repository.

What is the impact to users?

For end users that interface with the system through dashboards, the REST API, or any language client, the impact will be minimal provided no deprecated features are being used. Our adherence to semver means that anything removed from the API must have been deprecated in the prior major version before removal. Users are able to inspect response headers and deprecation logs for warnings about usage of deprecated features prior to upgrading.

For operators and system admins, upgrading may require updates to the deployment environment (particularly if not using the bundled JDK). Any operator that is hosting custom plugins will need to make code changes to the custom plugin to make it compatible.

Are in-place updates possible?

Yes. In-place updates are defined as either a rolling update (deactivate a host, update the software, and restart it, repeating for all nodes in a cluster) or a blue-green update (add new nodes to the cluster running the new software version, then remove the old nodes). OpenSearch 3.0 will be wire-compatible with the last minor version of the 2.x line and therefore capable of an in-place upgrade from that version to any 3.x version.

Any index data that was written with OpenSearch 1.x (or ES 7.x) must be re-indexed into OpenSearch 2.x prior to upgrading, as OpenSearch and Lucene only support reading data written by the previous major version. See the compatibility documentation for more details.

What about OpenSearch 1.3?

It will become end-of-life in open-source and the OpenSearch Project will no longer release updates.

What about OpenSearch 2.x?

The OpenSearch Project will continue to maintain the last 2.x release with regularly scheduled patch releases containing security fixes or other critical updates. This support will last until a 4.0 release happens, per the current maintenance policy.

What about clients?

Clients provide a super-set of APIs in order to make them compatible with multiple major versions. Existing clients should work with a 3.0 version, provided no previously-deprecated APIs are called by the end user. See the OpenSearch meta issue detailing breaking changes, including removal of previously-deprecated APIs.

[dblock]

I opened opensearch-project/opensearch-clients#78 for client support.

[peterzhuamazon]

Thanks @andrross ,

Based on this issue we have also proposed the new release schedule of 2025 here:

• [PROPOSAL] OpenSearch Release Schedule for Year 2025 #252

Please take a look and provide feedback. Thanks!