-
Notifications
You must be signed in to change notification settings - Fork 884
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
[Versioning] Release Process and Versioning for OpenSearch Dashboards #226
Comments
Cross referencing from here i.e if it starts with 1.0 the main will be 2.0 and have corresponding branch for 1.x. All new features goes in to main and then get back ported to 1.x. There are two possible paths to move forward
I believe we can go either one of them, but for I would prefer to go with main as 1.0 and then make the decision later on. @nknize what I feel if we make man 1.0 will it block others Open PR merge ? |
There might be multiple long term support major versions. Let's say 1.9 is last 1.x. Next is 2.0 The version branching strategy should take these into consideration |
The good news is this isn't a one way door. We can always switch main out to be last stable if we decide later to go that route. To start I strongly advocate we mirror the Lucene approach (since it's well vetted and our "upstream" that will force breaking changes). Here's an example of the branches we would have if we were working long term on the next release as 3.0.0.
Each branch is the next release ( bugfix, minor, or major) so we always have working branches we support (patch or fix), and tags are used for the releases. The nightly builds also have build id enabling us to always link back to the commit sha of any build. The only drawback is cherry-picking back ports but if that were a real problem then we probably would've abandoned it on Lucene long ago. |
[WIP] Additionally, I would like to discuss on compatibility between versions of OpenSearch and OpenSearch Dashboards. There are two possible approaches
Pros:
Cons:
Pros:
Cons:
|
Though compatibility is always associated with version strategy. It should be worth to have a separated thread to discuss.
|
Closing this since we released 1.0 and have our RELEASING.md: https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/RELEASING.md Feel free to reopen or create a new issue to discuss compatibility, long-term support, etc. |
…earch-project#226) * ui update: workspace create page Signed-off-by: yuye-aws <yuyezhu@amazon.com> * implement cancel button and wrap string with i18n Signed-off-by: yuye-aws <yuyezhu@amazon.com> * eslint fix Signed-off-by: yuye-aws <yuyezhu@amazon.com> * breadcrumb bug fix Signed-off-by: yuye-aws <yuyezhu@amazon.com> * workspace create unit tests Signed-off-by: yuye-aws <yuyezhu@amazon.com> * bug fix Signed-off-by: yuye-aws <yuyezhu@amazon.com> * update bread crumbs for workspace create page Signed-off-by: yuye-aws <yuyezhu@amazon.com> * udpate test case Signed-off-by: yuye-aws <yuyezhu@amazon.com> * optimize create page ui Signed-off-by: yuye-aws <yuyezhu@amazon.com> * update test file Signed-off-by: yuye-aws <yuyezhu@amazon.com> * change library category definition Signed-off-by: yuye-aws <yuyezhu@amazon.com> * remove key definition Signed-off-by: yuye-aws <yuyezhu@amazon.com> * change default permission type to Read Signed-off-by: yuye-aws <yuyezhu@amazon.com> * refactor bottom bar and cancel modal into components Signed-off-by: yuye-aws <yuyezhu@amazon.com> * declare consts outside functional components Signed-off-by: yuye-aws <yuyezhu@amazon.com> * remove key definition Signed-off-by: yuye-aws <yuyezhu@amazon.com> * refactor bottom bar and cancel model Signed-off-by: yuye-aws <yuyezhu@amazon.com> * Update src/plugins/workspace/public/components/workspace_updater/workspace_updater.tsx Co-authored-by: SuZhou-Joe <suzhou@amazon.com> * Update src/plugins/workspace/public/components/workspace_creator/workspace_permission_setting_panel.tsx Co-authored-by: SuZhou-Joe <suzhou@amazon.com> * Update src/plugins/workspace/public/components/workspace_creator/workspace_permission_setting_panel.tsx Co-authored-by: SuZhou-Joe <suzhou@amazon.com> * wrap string with i18n Signed-off-by: yuye-aws <yuyezhu@amazon.com> * reimplement tab selection to enum Signed-off-by: yuye-aws <yuyezhu@amazon.com> * fix data-test-subj duplicate bug Signed-off-by: yuye-aws <yuyezhu@amazon.com> * update tests and id Signed-off-by: yuye-aws <yuyezhu@amazon.com> * update UI Signed-off-by: yuye-aws <yuyezhu@amazon.com> * track the number of errors Signed-off-by: yuye-aws <yuyezhu@amazon.com> * add test cases Signed-off-by: yuye-aws <yuyezhu@amazon.com> * resolve conflicts Signed-off-by: yuye-aws <yuyezhu@amazon.com> * hide permission section when workspace permission is not enabled Signed-off-by: yuye-aws <yuyezhu@amazon.com> * sort permissions decreasingly Signed-off-by: yuye-aws <yuyezhu@amazon.com> * update test file Signed-off-by: yuye-aws <yuyezhu@amazon.com> * feat: remove some error and optimize mock Signed-off-by: SuZhou-Joe <suzhou@amazon.com> * feat: update Signed-off-by: SuZhou-Joe <suzhou@amazon.com> * update test file Signed-off-by: yuye-aws <yuyezhu@amazon.com> * refactor with EuiTab Signed-off-by: yuye-aws <yuyezhu@amazon.com> * remove sort logic Signed-off-by: yuye-aws <yuyezhu@amazon.com> * remove unused import Signed-off-by: yuye-aws <yuyezhu@amazon.com> --------- Signed-off-by: yuye-aws <yuyezhu@amazon.com> Signed-off-by: SuZhou-Joe <suzhou@amazon.com> Co-authored-by: SuZhou-Joe <suzhou@amazon.com>
What is our release cadence
What model of versioning will be used?
New forks will start using the Apache Versioning
How will OpenSearch and OpenSearch-Dashboards versions be related to each other?
OpenSearch Dashboards and OpenSearch will release major version together. They will NOT synchronize minor release — whenever the team feels they’re ready to release a minor version or patch (modulo the schedule above), they should release.
What we guarantee is that any major release of OpenSearch Dashboards is compatible with the same major release of OpenSearch. For example: 3.2.1 of NotKibana will work with 3.0.4 of NotElasticsearch, but 2.3.1 of NotKibana is not guaranteed to work with 3.0.4 of NotElasticsearch
Breaking Changes and Backwards Compatibility
We will not release any breaking changes except in major releases.
More on versioning has been discussed opensearch-project/OpenSearch#95
The text was updated successfully, but these errors were encountered: