Implement OpenSearch core branching strategy

[prudhvigodithi]

Description

Ensure MAJOR_VERSION.x branch exists, the main branch acts as source of truth effectively working on 2 versions at the same time.

Related META issue

opensearch-project/opensearch-plugins#142

Current Behavior

Currently plugins follow a branching strategy where they work on main for the next development iteration, effectively working on 2 versions at the same time. This is not always true for all plugins, the release branch or branch pattern is not consistent, the lack of this standardization would limit multiple automation workflows and alignment with core repo. More details on META ISSUE

Proposed solution

Follow OpenSearch core branching. Create 1.x and 2.x branches, do not create 2.0 as a branch of main, instead create main -> 2.x -> 2.0. Maintain working CI for 3 releases at any given time.

[ps48]

@prudhvigodithi We've updated branches 1.x and 2.x (created from 2.1).

[ps48]

@prudhvigodithi waiting for job-scheduler to merge in 3.0

[dblock]

@ps48 That was done.

[ps48]

Status:

• main is building 3.0 -> Currently fails at bwc testing stage.
• 2.x is building next 2.x, which is currently 2.4.0
• 2.3 is building next 2.3, which is 2.3.1
• manifests in https://github.com/opensearch-project/opensearch-build/tree/main/manifests include all 3
  • manifests update in 2.4.0 pending here: Observability 2.4.0 opensearch-build#2696

[ps48]

3.0 merge to main is blocked by manifests update 2.4.0 PR pending in opensearch-build repo.

[ps48]

Waiting for 2.4.0 dist. build to be successful on OS side. This is needed to merge 3.0.0's bwc testing.

[ps48]

2.4.0 artifact is available. 3.0.0 build fails due to upstream changes from common utils: opensearch-project/common-utils#281

[bbarani]

@ps48 re-tagging the issue with 2.4.0 release.

[ps48]

The branches are updated and added to build. Closing the issue.