[DOCS] Versioning & Compatibility policy

[Xtansia]

The versioning and compatibility policy as laid out here needs revisiting.

It needs v2.0 added to the compatibility matrix as it is in COMPATIBILITY.md

Additionally we do not necessarily intend for client versioning to remain in major version lockstep with the server. ie. if it's possible to support the future OpenSearch 3.0 server without introducing breaking changes to the client, the client will remain v2.

[AbhinavGarg90]

Hey, what exactly needs to be done to resolve this issue?

[Xtansia]

There's two things that need adjusted in this comment:

• A very simple addition of a | 2.x | 2.x | row to the compatibility table.
• There needs to be some re-wording (especially the line A major version of the client is compatible with the same major version of OpenSearch.) as we don't intend to always be in the policy of client version N.x.x matches to server version N.x.x.

@dblock Do you have thoughts about how we might word that latter part?

[dblock]

I would remove that lengthy comment altogether.

OpenSearch server now follows semver, so should client. Make it independent. Compatibility != support for all features. Trying to match server version is limiting, clients are separate applications and should evolve separately.

In the compatibility matrix I'd like to see things like opensearch-rs 6.1 is compatible with OpenSearch 1.x and 2.x. When I look for a specific API added in OpenSearch 2.12, I'd want to find in CHANGELOG something like "opensearch-rs 6.2 adds support for OpenSearch 2.12 spline/reticulate API". Note that 6.2 would still be compatible with 2.10 or 2.12, just may not have all features (yet).