Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discuss] Versioning strategy #8

Open
nknize opened this issue Jun 30, 2021 · 3 comments
Open

[Discuss] Versioning strategy #8

nknize opened this issue Jun 30, 2021 · 3 comments

Comments

@nknize
Copy link

nknize commented Jun 30, 2021

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
Copy link
Collaborator

AmiStrn commented Jul 2, 2021

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
Copy link
Collaborator

AmiStrn commented Jul 5, 2021

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

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

@rursprung
Copy link
Contributor

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants