We need to a 2.17.x branch which created from 2.17.0 tag for patch goes to 2.17

[seraphjiang]

After 2.17.0 release, we 2.x has bump up version to 2.18, and it is used for 2.18 development.

In the case we need a patch release, we need a dedicated branch for people to backport/cherry pick or merge the planed fix. To follow the same conversion like 2.x, we need 2.17.x for this purpose.

this branch will only contains 2.17.x patch, the version is always 2.17.(x+1) x is offical last patch number. as of 9/23, we have 2.17.0. so the version is 2.17.1, once we released 2.17.1, it should be bump up to 2.17.2

[ashwin-pc]

If we know that a bug should go in 2.17.1 why not merge the change into the 2.17 branch? why add another hop? If we are not sure if it needs to go in 2.17.1, merge it into 2.x until we make the decision and them backport it to 2.17. Im not sure i see the point of keeping a change in a holding branch called 2.17.x. We will also be adding a lot of branches this way.

Also lets have this discussion in the .github repo since this is a pattern we should follow as an org so that we dont diverge. @opensearch-project/admin can you transfer the issue there?

[seraphjiang]

we use 2.x for all minor development, why not 2.17.x for patch development?

about why 2.17 is not good, what i heard from @getsaurabh02 is that we should only cherry pick PR we plan to release.

today, there are 500 branch in OSD, what are we afraid of to create patch branch 2.17.x ?

[ashwin-pc]

about why 2.17 is not good, what i heard from @getsaurabh02 is that we should only cherry pick PR we plan to release.

That i dont agree with. Whats the point of a fix we dont release. if we are taking the effort to patch 2.17 and put the change there, we should not be hesitant in releasing it as well. Having a dangling branch that has not scope of being released is what i dont think is a good idea. If we dont want to release it, why even bother backporting it.

[seraphjiang]

i don't think is a good idea. If we dont want to release it, why even bother backporting it.

not all commit need a release. as long as people contribute to repo, review and get merged it is valuable. i don't know what qualify for dangling what are not. for 532 branch we have today, what are dangling? do we have process to define that, include the process to clean up.

the only reason we support only last minor for two major version is lack of official support. but why stop people to contribute if they want to?

[getsaurabh02]

Thanks, @seraphjiang, for opening the issue. However, I disagree with forking another branch to 2.X.Y. It doesn't add value to the OS release and only complicates the branching strategy, making it harder to manage with additional branches and backports.

I completely agree with the points raised by @ashwin-pc below. Thanks, @ashwin-pc!

If we know that a bug should go in 2.17.1 why not merge the change into the 2.17 branch? why add another hop? If we are not sure if it needs to go in 2.17.1, merge it into 2.x until we make the decision and them backport it to 2.17. Im not sure i see the point of keeping a change in a holding branch called 2.17.x. We will also be adding a lot of branches this way.

For any other purposes, such as isolated development and testing, as a maintainer you can always create a feature branch, such as 2.17-fixes which could be fork from 2.17, for isolated testing and development.

[seraphjiang]

@getsaurabh02 it is not clear how to handle the patch release in the process with branch strategy. what you describe approach to create a feature branch is against the definition of patch release, don't introduce feature in patch release.

because lack of clarity of the branch strategy. it leads to 2.17 is not well maintained, it cause this PR #8323 to revert 10 PR in order to release 2.17.1

also i'm not sure if the revert decision is well communicated to community. Hope it is tracked somewhere, why make such decision.

The process of patch release/branch should be clarified for the gap and make it correct for the future release to avoid confusion to the community.

[seraphjiang]

@getsaurabh02 would you move this issue to .github, i think there is big gap in patch release process/branch strategy, and worth to discuss broadly.