[Discuss] Versioning strategy

[nknize]

OpenSearch plugins are attempting to version independently from core OpenSearch but also support a "npm" or "ruby gem" like dependency versioning approach. This issue is intended to capture discussion around how that's supported in the template and what kind of "scaffolding" might help make this easier for the plugin repositories.

[AmiStrn]

First issue 🎈 🔔 🥳
This is a good point to discuss.
By

attempting to version independently from core OpenSearch

do you mean that the gradle file would not require the version of opensearch that the plugin is to be installed into?
Or that there should always be a main, 1.0 and 1.x branch here?

The build tools for plugins would have to be part of the "npm" you mention in my opinion.

[AmiStrn]

@nknize i just noticed:
opensearch-project/opensearch-plugins#35

I think this issue can be discussed over there as well. WDYT?

[rursprung]

since opensearch-project/OpenSearch#11441 it should technically be possible for plugin releases to be de-coupled from OpenSearch releases? though the usage of the gradle plugin currently blocks this as it doesn't support it yet: opensearch-project/OpenSearch#14560 (the overall tracking issue for this now seems to be opensearch-project/OpenSearch#14560)

once the de-coupling is complete there should be no reason for the plugins to continue matching 1:1 the OpenSearch releases and they can start following semver practices (i.e. example-plugin v1.0.0 can be compatible with OpenSearch >= 2.17.0, then bump to example-plugin v2.0.0 because there was a breaking change for consumers while still being compatible with the same (or a different) OpenSearch release range). for existing plugins which can de-couple it should be fine to then just continue with semver starting at whichever version they were because of OpenSearch (and probably going from a 4-digit version number to a normal 3-digit one).