anastead
commented
5 hours ago Thanks Andrew for the detailed proposal. I am voting for 8 week interval/cadence.
Open andrross opened 6 hours ago
anastead
commented
5 hours ago Thanks Andrew for the detailed proposal. I am voting for 8 week interval/cadence.
Pallavi-AWS
commented
4 hours ago Thanks Andrew for capturing the pros/cons of changes in release cadence. My vote (as proposed in TSC) continues to be 8 weeks.
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?
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.