Standardize release, branching and labeling process for all org repos

[dblock]

Coming from opensearch-project/opensearch-plugins#35, and #11, but that merges OpenSearch, OpenSearch Dashboards and plugins.

• OpenSearch - Updated READMEs on releasing, maintaining, admins and security. OpenSearch#853
• OpenSearch Dashboards - Document release branching OpenSearch-Dashboards#527
• Plugins - Standardize processes across all plugins opensearch-plugins#41

[dblock]

Let's also add text to https://github.com/opensearch-project/.github/blob/main/RELEASING.md about backporting changes.

[ohltyler]

@dblock copying the comment to the main tracking issue here:

Few questions about the differences between core & plugins:

1. Branches - with ODFE, branches followed the convention opendistro-<major>-<minor> - shall we do the same now but with opensearch-<major>-<minor>?
2. Tags - plugins have a 4th digit for plugin-related patching changes - shouldn't the labels be v1.0.0.0, etc, instead of just 3 digits like core?

[dblock]

1. Branches - with ODFE, branches followed the convention opendistro-<major>-<minor> - shall we do the same now but with opensearch-<major>-<minor>?

I find that rather unusual or unnecessary since It's not like we release plugins for multiple targets, and so I would just do what engine does and call them -.

2. Tags - plugins have a 4th digit for plugin-related patching changes - shouldn't the labels be v1.0.0.0, etc, instead of just 3 digits like core?

A version target is useful when you work on multiple releases, so while this sounds like a good idea, I think we will quickly end up with tons of labels, so maybe there should be a next patch label? WDYT? Open a PR into this repo with what you think we should do?

[ohltyler]

I find that rather unusual or unnecessary since It's not like we release plugins for multiple targets, and so I would just do what engine does and call them -.

Makes sense. I'm ok with removing the prefix and just going with <major>-<minor> for consistency with core.

A version target is useful when you work on multiple releases, so while this sounds like a good idea, I think we will quickly end up with tons of labels, so maybe there should be a next patch label? WDYT? Open a PR into this repo with what you think we should do?

I think this seems reasonable. That way the versions are always aligned with core, and plugins can maintain any patches with a patch label. I'm thinking patch instead of next patch, since we may have some patch (like a security or bug fix) that we will want to backport to older versions, instead of treating it as a patch only for the upcoming / current release.

I'll open a PR - can continue discussion there.

[ohltyler]

@dblock opened #17. I'm unable to add reviewers due to maintainer and/or write access issues. Please take a look there. Thanks!

[dbbaughe]

@dblock

It seems with the current model we have plugins building from the equivalent branches for dependent plugins and upstream OpenSearch/OpenSearch Dashboards.

I'm not a fan of this model for plugin development. I don't like the fact that contributors across our plugins can be opening a PR to our main branch (i.e. our development branch) for some foobar feature and have it passing and then you rerun the test and now it's failing because a contributor in OpenSearch made some change that broke something in plugins or caused an issue in OpenSearch itself that is now causing downstream plugin repos compile/install/tests to be failing.

I do understand it helps catch regressions in OpenSearch itself and warns plugin developers of possible impending breaking changes, but it should not cause friction down to the plugin repositories to the point of blocking PRs. If a plugin developer sees things start breaking in a PR they will more than likely assume something is wrong with their code and work on fixing it. They might have zero experience w/ OpenSearch upstream and waste a lot of time on something that had nothing to do with their changes.

Plugins should be developing based on the latest stable release and if we want to catch regressions in OpenSearch for the plugin framework then there should be

1. more tests in OpenSearch for the plugin framework if we feel we are lacking, that being said there are a lot of plugins already in OpenSearch so these should be getting tested.
2. OpenSearch can pull the official supported plugins and do a compile/install/test check to see if the change broken something downstream. Although it'll run into the same issue of if the plugins branch is flaky or failing now it'll cause unwanted fatigue on OpenSearch having to know if they broke something or it was the plugin.

[dblock]

Plugins should be developing based on the latest stable release

The OpenSearch product/bundle model is a single release of core + all plugins. Sounds like a catch-22.

[dblock]

I am going to close this. We have https://github.com/opensearch-project/.github/blob/main/RELEASING.md#branching, which likely actually belongs in opensearch-plugins, opensearch-build or a combination of those.