Document and standardize release and branching strategy for plugins

[saratvemulapalli]

For all OpenSearch/Dashboards plugins, as we work on releases we should have a release and branching strategy.

Release Branching

Given the current major release of 1.0, projects in this organization maintain the following active branches.

• main: The next major release. This is the branch where all merges take place and code moves fast.
• 1.x: The next minor release. Once a change is merged into main, decide whether to backport it to 1.x.
• 1.0: The current release. In between minor releases, only hotfixes (e.g. security) are backported to 1.0.

Label PRs with the next major version label (e.g. 2.0.0) and merge changes into main. Label PRs that you believe need to be backported as 1.x and 1.0. Backport PRs by checking out the versioned branch, cherry-pick changes and open a PR against each target backport branch.

1. Create a RELEASING.md in your repo or add a Releasing section to your README that links to https://github.com/opensearch-project/.github/blob/main/RELEASING.md, e.g. This project follows [OpenSearch branching, labelling, and releasing](https://github.com/opensearch-project/.github/blob/main/RELEASING.md).
2. Make sure you have a main, 1.x and 1.0 branch with the right code.
3. Review your branches, delete any unused or merged ones.

Plugin checklist:

• alerting
• anomaly-detection
• asynchronous-search
• data-prepper
• index-management
• job-scheduler
• k-NN
• opensearch-notebooks
• performance-analyzer
• reports-scheduler
• security
• sql

[nknize]

Here's the release / branching approach for core OpenSearch

[saratvemulapalli]

@dblock I know we made some steps forward, is there still work here?

[dblock]

Let's close.