[Versioning] Release Process and Versioning for OpenSearch Dashboards

[boktorbb]

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

[mihirsoni]

Cross referencing from here
Hi @dblock Lucene follows the main being always next major version.

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

• Follow what Lucene follows, which makes our main to 2.0 and it can take all the new features and back ported to 1.x as needed.
• Keep main as stable and current version, i.e main branch will be 1.0 and cut a branch when release is scheduled.

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 ?

[seraphjiang]

There might be multiple long term support major versions.

Let's say 1.9 is last 1.x. Next is 2.0
When move to 2.0, there are still user using 1.9, they will need long term support.

The version branching strategy should take these into consideration

[nknize]

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.

• main == 3.0.0 alpha
• 2.x == 2.4.0 alpha
• 2.3 == 2.3.5 (tags for all the rest)
• 2.2 == 2.2.8 (tags for all the rest)
• 2.1 == 2.1.4 (tags for all the rest)
• 2.0 == 2.0.6 (tags for all the rest)
• 1.x == 1.5.0 alpha
• 1.4 == 1.4.6 (tags for all the rest)
• 1.3 == 1.3.4 (tags for all the rest)
• 1.2 == 1.2.5 (tags for all the rest)
• 1.1 == 1.1.6 (tags for all the rest)
• 1.0 == 1.0.4 (tags for all the rest)

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.

[mihirsoni]

[WIP] Additionally, I would like to discuss on compatibility between versions of OpenSearch and OpenSearch Dashboards.

There are two possible approaches

Tightly coupled with OpenSearch engine.

Pros:

• One time deployment for users.

Cons:

• Release will always have to tie together with engine.

Break the chain and only sync with major version release and release independently minor version.

Pros:

• Dashboards can prepare and plan their own release

Cons:

• Users will have to plan different deployments and maintenance window for their production grade cluster.

[seraphjiang]

Though compatibility is always associated with version strategy. It should be worth to have a separated thread to discuss.
Here is some general thinking.

• OpenSearch might has its own compatibility strategy overall to its downstream application. (Dashboards is one of them)
• OpenSearch general guideline about forward compatibility and backward compatibility. e.g. we add new API for major.minor increase, but only break interface like actual deprecate API when major version increased.
• Dashboard's own compatibility guideline, including when integrate with same, prior, future version of OpenSearch. Assume future version must be support in order to run upgrade scenario.
• Dashboards has its own APIs, there will be downstream application built on top that. we also need to come up Dashboards' guideline to ensure, Dashboards developer won't break interface under certain version rule.
• If we have to break public interface/API like modify, remove, we need to document it well in release note or SDK documentation.

[tmarkley]

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.