[PROPOSAL] Finalize 2024 release schedule for OpenSearch #186
Comments
|
Big thanks @bbarani for putting together this great detailed release proposal !! First thing first, my vote goes to Option 2 :) (just can't wait for the rolling out of 3.0) Yet meanwhile I do understand there could be a large load of action items involved just to support 3.0, let alone supporting 1.x and 2.x at the same time. So maybe we could take a bolder move to skip more releases in the 1.x and 2.x line just to ensure the release of 3.0 in late2024/early2025 (definitely don't want to skip any releases.. if we have the super power lol) IMHO, currently the 1.x release line mainly focuses on the security fix (CVE fixes precisely) and any reported critical bugs fix which should come with minimum load of code changes, also support of 1.x will reach an end once 3.0 goes live anyway, so skipping one more 1.x release say 1.3.20 won't bring in much troubles. On the 2.x release line, instead of skipping maybe postponing would be more accurate, where maybe we just reschedule the release of 2.17.0, from September 17 2024 to sometime in 2025, where 3.0 is already GAed and 2.x continues to fall within the support window, yet like the 1.x line today, mainly with security and bug fixes but major feature development work will be shifted to 3.x and new main (targeting 4.0) It would gives us more time, say after release of 1.3.19 on August 27 2024, we just fully focus on the release of 3.0, and the stretch goal or the existing goal would be to release 3.0 as soon as possible :)
|
|
One observation: the intervals(days) between minor/major versions of 2.x/3.0 don't seem to be even. Just curious if there are any special considerations.
|
|
@bbarani a few more to 3.0.0, my concern is Apache Lucene 10 (no date AFAIK): |
|
While the prospect of a 3.0 release is very exciting, I vote option 1 and want to highlight some of the reasons for others' consideration.
As shared in Barani's awesome summary, a move to 3.0 in 2024 does not mean we drop 1.x in 2024. Instead we will be increasing the maintenance load (probably doubling it realistically--I assume 3.0 will require at least as much work as 2.x). This means repos will need to dedicate even more of their limited time to managing releases and making sure things are ready to ship. As seen with the 2.12 release, this is no small task; if we have to shift our releases already, how can we commit to delivering a high quality project when we add even more load on contributors?
As we all know a leadership committee was formed with various stakeholders from around the project. This committee is in the process of determining how to move OpenSearch into a foundation such as Apache or Linux. I suspect any movement will require at least some effort from the maintainers of the project. It seems unlikely that the move will be completely "clean" or just a change of regulations. Maintainers will likely have to be involved in some efforts to refactor or restructure things to meet new requirements. Trying to do this while releasing 3.0 seems risky.
My final point is that it seems like some of the proposed breaking changes have pretty minimal input from the community. For instance, the issue focusing on admission control has been open since May 2023, and has no comments or details. I don't think we should be driving the project based on abstracts or what-ifs. If we move to 3.0 I feel we need to have a concrete list of heavily requested and bought-in changes which the community has actively discussed. Whether this occurs during a community meeting or elsewhere, I would want to see more discourse around changes before we use them as justification for a 3.0. (This is not saying that the Admission Control RFC is a bad idea or anything, just that there has not been much engagement or follow-up). I don't know what number of breaking changes would justify a 3.0 or whether the magnitude of a change should make it worthwhile on its own (for instance the Lucene bump). TL;DR: I vote for option 1 unless we can get safeguards in place to make sure we have sufficient community support, know the costs for each release, and are certain that a 3.0 release will not slow movement to a foundation. |
@seraphjiang Major versions usually require additional preparation time and release cycle time due to the sheer number of breaking changes, features, documentation, infrastructure setup, security review and extensive testing hence added some buffer for 3.0 versions. |
|
Regarding potential breaking changes for 3.0, here are a couple more:
|
Added these items to the 3.0 breaking changes list. CC: @andrross |
|
I am with @ZilongX on this one and would prefer Option 2. In my org we prefer dealing with breaking changes sooner than later and in this case I think it would benefit the project in the long-run to focus development on 3.x a little earlier. I don't have any actual insight into the OpenSearch codebase since I am not a dev, but I have a gut feeling that possibly some work done on 2.x needs to be done twice for it to work with 3.x and if we could limit the changes required for 3.x this could speed up future development. |
|
There's a significant amount of divergence in 3.x, and the cost of the gap will continue to compound. I vote for option 2. |
|
Add an OSD 3.0 breaking change opensearch-project/OpenSearch-Dashboards#5639 |
|
Can the teams tagged with breaking changes evaluate if the changes are indeed breaking or can be done in a backward compatible manner? |
|
While there are pros and cons to both options, I think option 1 is better since upgrading to a new major version requires significant work for everyone in the community. Some of these features in the list we can probably introduce in 2.x as optional (e.g., protobuf support) |
|
Hey, I'm confused. In our docs we say about major versions:
Are we saying we think regardless of Lucene, we have a critical mass of breaking changes and we want to plan a release? When I look at that list, I don't see a critical mass, but I could be might be missing context. In general we have tried really hard to not to upgrade to a major because it puts work on people using the software. Long story short, I would propose that you separate out the minor release schedule from the "do we want to release 3.0 outside of Lucene's schedule" issue. On that topic, my personal opinion is to wait as long as possible, where as long as possible is the next Lucene release. Finally, if we want to change the project's position on major releases, we should bring it up to the LC. They own the scope of releases timings :) |
|
A big feature for 3.0 is HTTP/2 support. This is not possible without a breaking change. |
Added it to the list. |
|
Gentle reminder, we will be finalizing the release plan for 2024 by Feb 15 2024 so please make sure to add your comment with your recommended option before then. |
Can we direct those comments towards a pull request that documents the updated release plan? |
|
I have raised a PR with Option 1 release schedule based on the votes from the community and recommendation by OpenSearch leadership committee. Please add your review comments and feedback directly to the PR. CC: @Pallavi-AWS @peternied |
|
Closing this issue as we have finalized the 2024 release schedule for OpenSearch and the PR has been merged now. |
|
I am late for the party though my input during the LC meetings was to delay 3.0 if possible so option 1 was my preference. |
Introduction:
OpenSearch follows semver for versioning, which means we only release breaking changes in major versions. For our minor and patch releases we follow release window model, where we release around 6 weeks and the schedule is published published on OpenSearch.org at the beginning of the year.
Currently we are building and releasing minor, patch releases for 2.x and patch release for 1.x line. For 2.x, we have planned OpenSearch releases till 2.12.0 version but we haven’t planned any additional releases for 2024 yet.
We would like to get your feedback on this 2024 release schedule proposal to finalize the options before updating the OpenSearch release calendar.
Please provide your feedback and recommendation by commenting on this issue by Feb 15 2024 in order for us to update the 2024 release calendar in timely manner.
We have come up with 2 possible options but we welcome any additional options from the community.
Option 1:
Keep supporting 2.x minor version and 1.x patch version in 2024 and plan for 3.0 release in 2025.
Option 2:
Keep supporting 2.x minor version and 1.x patch version in 2024 but skip few 2.x version in 2024 to prioritize 3.x release. We will need to support 1.x, 2.x and 3.x versions in 2024 until 3.0 GA version is released in 2025.
Breaking changes planned for 3.0.0 release:
OpenSearch:
More to come....
Possible to introduce in 2.x line in backward compatible manner
Move Job Scheduler plugin to core (modules) job-scheduler#147[RFC] Admission Control mechanism for Cluster Manager APIs OpenSearch#7520OpenSearch dashboards:
More to come....
Frequently asked questions (FAQ):
How long will the 1.x version be actively supported?
We will continue to release patch versions for 1.x until the GA release of 3.0 version is released as mentioned on release schedule page. 1.x version will become end of life (EOL) once the GA release of 3.0 version is released.
When will 2.x version go in to maintenance mode?
Minor and patch releases for 2.x version will be supported until GA version of 3.0 is released. 2.x line will go in to maintenance mode ( i.e. only patch version will be released) once GA version of 3.0 is released.
Is there a plan to release 3.0 version in 2024?
The plan to release OpenSearch 3.0 version in 2024 is not yet finalized. Major versions will include breaking changes hence we will release release candidate (RC) version followed by GA release for 3.0 version. We will work with the community to take the decision based on the finalized outcome of options listed on this issue.
Why do we need to release a new major (3.0.0) version?
We have documented few breaking changes that are not compatible with 2.x versions but beneficial to the OpenSearch community in this issue. OpenSearch follows SemVar versioning and as per their guidelines, we can include the breaking changes in a MAJOR version (3.0) only.
What versions of OpenSearch will be actively supported post the release of 3.0 GA version?
We will support the patch releases for 2.x versions and minor, patch releases for 3.x versions post the release of 3.0 GA version.
How to provide the feedback or suggestions?
Please provide your feedback with your preferred option by commenting on this issue. Feel free to add any other breaking changes (not listed on this issue) that would warrant a major release (3.0) in the comment as well.
We welcome any additional feedback from the community!!!
The text was updated successfully, but these errors were encountered: