[RFC] Create a 0.x branch

[seankao-az]

Problem Overview

Our current branching strategy faces several challenges:

1. There's no clear path for introducing new features and improvements in a stable manner between minor releases.
2. The main branch is unsuitable for continuous deployment due to potential instability and breaking changes intended for future major releases.
3. The latest minor release branch (0.6) doesn't include new features and improvements, making it inadequate for continuous deployment.
4. We're maintaining a custom branch for continuous deployment, cherry-picking desired commits from the main branch onto the 0.6 branch. This approach is unsustainable and time-consuming.

Proposed Solution

Implement a new branching strategy inspired by OpenSearch branching:

We'll maintain three primary branches:

1. main: Development for the next major release (e.g., 1.0)
2. 0.x: The next minor release (e.g., 0.7), used for continuous deployment
3. 0.6: The current stable release

The workflow is as follows:

1. Merge all new development into the main branch
2. Backport stable, non-breaking changes from main to the 0.x branch
3. Use the 0.x branch for continuous deployment
4. Cut new minor releases from the 0.x branch
5. Backport critical bug fixes to the 0.6 branch and other supported release branches

Benefits for this approach:

1. Provides a stable branch (0.x) for continuous deployment
2. Allows for new feature introduction between minor releases
3. Maintains stability in the release branches
4. Simplifies the process of managing multiple versions
5. Eliminates the need for a custom deployment branch

[YANG-DB]

Hi @seankao-az - thanks for this suggestion !

I would like to offer another approach:

Follow OpenSearch release cadence including the versioning semantics - so we are aligned with OpenSearch project.

Why is this good:

1. We will align all the artifacts that have a dependency with opensearch in an identical versioning schema that will remove versioning matching compatibility issues and potential errors.

2. We will have a known schedule of release cadence which will converge our artifact with the global project's artifacts

3. We will have a direct feature compatibility alignment for PPL language support both on Spark And OpenSearch where we can maintain same language features supported for the same version
   A new PPL feature will be presented both on SQL & Spark repositories in the same version and released in the same time

4. By aligning with the project's processes and delivery mechanism we benefit the publication and awareness of the community of our versions and take part in the docker-hub released artifacts

All the benefits mentioned above are kept

• Allows for new feature introduction between minor releases
• Maintains stability in the release branches
• Simplifies the process of managing multiple versions
• Eliminates the need for a custom deployment branch in this approach:

Why is this not so good:

The only negative implication IMO is that we will need to release in a time interval that is not always aligned with our work. Fortunately, this is the case for many other opensearch projects and by adapting the time frame of the general project we will be able to adopt its processes and schedules and enjoy its benefits

---

Branch naming strategy

In a similar way to OpenSearch supporting 3 branches :

• main: Development for the next release
• 2.x : The next minor release
• 2.18 : The current stable release

[seankao-az]

I think it's a good thing we don't tie with the OpenSearch versions. We only upgrade our dependency for OpenSearch when there's new feature or fixes when we need it.
And I think one of the motivation for separating the aysnc-core library from the sql repo is so that its release schedule can be independent of the OS release schedule

[ykmr1224]

+1 to separating versioning from OpenSearch version. That force us to make release every time when OpenSearch release new version.
I am wondering if we have strong motivation to have separate branch for next major release and minor release for now. I think that is needed once we have plan for next major release (like some feature planned only for next major release). Having separate branch would increase the maintenance cost.

[andy-k-improving]

I think it's a good thing we don't tie with the OpenSearch versions. We only upgrade our dependency for OpenSearch when there's new feature or fixes when we need it. And I think one of the motivation for separating the aysnc-core library from the sql repo is so that its release schedule can be independent of the OS release schedule

I share the same thought, especially this Flink project doesn't exist in the form of OpenSearch plugin, like what https://github.com/opensearch-project/sql do, I don't see the necessity for the coupling in release version.

[seankao-az]

Having separate branch would increase the maintenance cost.

I think that is needed once we have plan for next major release

I think this makes sense. For deployment, is there any concern just using the main branch?