[PROPOSAL] Change OpenSearch release cadence for 2025

[andrross]

What are you proposing?

The OpenSearch release process specifies that a release schedule is published at the beginning of every year and that releases are spaced approximately every 6 weeks. This proposal is to increase the 6 week spacing before publishing the 2025 schedule. This proposal was discussed within the technical steering committee and the committee voted to recommend moving to an 8 week interval over staying at 6 weeks or extending to 12 weeks. This issue is to gather feedback from the community, and to discuss alternatives intervals such as 12 weeks, or staying with the 6 week cadence.

What users have asked for this feature?

The infra team selects a release manager to do the work of building, testing, and releasing the distribution for each release. This involves a significant time commitment during each release. Given that both 1.x and 2.x release happen, each with a 14 day release window, that means there are overlapping release windows requiring time from more than one person. The frequent releases means that the infra team has fewer resources to dedicate towards improvements and automation.

Feature teams have indicated that the 6 week cycle is too short to develop significant features, resulting in an interruption to manage and interim release before a feature can be completed for the next release. Additional time consuming processes like security reviews can make it very difficult to complete a feature within a single release cycle.

As a core maintainer, I have also observed the overhead with each release, mainly related to test failures across branches during the process of release branch creation / version increment. This takes developer time to root cause and fix failures, often slowing down other work that would otherwise not be involved in the release.

What problems are you trying to solve?

Ultimately the goal is to cut down on release-related overhead, ultimately leading to more investment in automation and tooling, which will further cut down on release-related overhead.

Why should it be built? Any reason not to?

Less frequent releases mean that users may have to wait longer to get new features or non-critical bug fixes.

Longer intervals mean more changes will go into each release, increasing the likelihood of integration failures. I have observed that releases with more changes (and more last-minute changes) are the most chaotic. It is possible that increasing the interval could be counter-productive and result in more overhead due to more problems and failures during the release process.

What will it take to execute?

Just an update to the release process defined in this repository and then publishing the new 2025 schedule.

Any remaining open questions?

• If we increase the interval, is 8 weeks the right number? Why not 12?
• Is the 14 dayrelease window during each release the right duration?
• We also continue to maintain the 1.3 version with patch releases. It currently releases at the same cadence as the 2.x versions. Should it continue to release at the same cadence (whatever we decide) or should it move to a longer interval?

Please note: this proposal applies only to regularly scheduled minor and patch releases. For "hot" patches (patches required for security or other urgent issues) we will build, test and release as quickly as possible.

[anastead]

Thanks Andrew for the detailed proposal. I am voting for 8 week interval/cadence.

[Pallavi-AWS]

Thanks Andrew for capturing the pros/cons of changes in release cadence. My vote (as proposed in TSC) continues to be 8 weeks.

[epugh]

Here are my thoughts, and I'll admit they come from my own narrow perspective:

• I don't run 1.x, so I don't know that my thoughts matter there. If major and minor features are not being ported back to 1.x, then I think it could be on it's own release schedule. I suspect that if you are on 1.x, you really aren't tracking the latest and greatest, and you probably update only based on a security issue. So you could even imagine a more "only a release when something big happens". I would like to see less emphasis on 1.x and more on 3.x!
• I would LOVE to see the releases timed to quarters. We tend to plan work on a quarterly basis, so the fact that January 1 is way after the 2.18 last release, but not much before 2.19 makes it hard to scope "Here is work we start Jan 1 and we want it in 2.19". If it's 8 weeks, could it be more or lease three cycles in H1 of year, and three cycles in H2? So with the last cycle in mid December?
• I like the longer release window. We iterate in two week cycles with a demo at the end of each one, which means typically our third "demo" misses the cut off for the six week cycle. Eight week cycles would let us build for three cycles, and then participate in release activities and buttoning up for 1 cycle.
• I maybe lean towards 8 weeks as it gives you six "bites at the apple" in getting your code out there in a year instead of four. If you miss a cut off with only 4, you are kind of in trouble!

[reta]

Indeed, things get very chaotic around the release date (the 2.18.0 is a notable exception). Although I personally would prefer to see more contained, smaller releases more often (like now, every 6 weeks), the overhead on release team / release managers is huge. I would vote to try out 8 weeks.

[peterzhuamazon]

I would also vote for 8 weeks from RE perspective as we would have more time to coordinate the release. As a compensate to the longer release cycle, users can try out the snapshots and nightly builds if they are more eager to update the versions for new feature or fixes.

We could use this opportunity to improve the visibility of those nightlys over time.

Thanks.