search

opensearch-project / .github

Provides templates and resources for other OpenSearch project repositories.
Apache License 2.0
28 stars 71 forks source link

[PROPOSAL] Finalize 2024 release schedule for OpenSearch #186

Closed bbarani closed 4 months ago

bbarani commented 5 months ago

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.

Release Number First RC Generated (release window opens) Latest Possible Release Date (release window closes)
1.3.15 Feb 27 2024 March 05 2024
2.13.0 March 19 2024 April 2 2024
1.3.16 April 16 2024 April 23 2024
2.14.0 April 30 2024 May 14 2024
1.3.17 May 28 2024 June 06 2024
2.15.0 June 10 2024 June 25 2024
1.3.18 July 09 2024 July 16 2024
2.16.0 July 23 2024 August 06 2024
1.3.19 Aug 20 2024 August 27 2024
2.17.0 September 03 2024 September 17 2024
2.18.0 October 22 2024 November 05 2024
1.3.20 December 03 2024 December 10 2024
2.19.0 January 28 2025 Feb 11 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.

Release Number First RC Generated (release window opens) Latest Possible Release Date (release window closes)
1.3.15 Feb 27 2024 March 05 2024
2.13.0 March 19 2024 April 2 2024
1.3.16 April 16 2024 April 23 2024
2.14.0 April 30 2024 May 14 2024
1.3.17 May 28 2024 June 06 2024
2.15.0 June 10 2024 June 25 2024
1.3.18 July 09 2024 July 16 2024
2.16.0 July 23 2024 August 06 2024
1.3.19 Aug 20 2024 August 27 2024
2.17.0 September 03 2024 September 17 2024
3.0.0 (RC1) October 28 2024 November 19 2024
1.3.20 December 03 2024 December 10 2024
3.00 (GA) January 28 2025 Feb 18 2025

Breaking changes planned for 3.0.0 release:

OpenSearch:

Possible to introduce in 2.x line in backward compatible manner

OpenSearch dashboards:

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!!!

ZilongX commented 5 months ago

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 :)

image

seraphjiang commented 5 months ago

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.

image

reta commented 5 months ago

@bbarani a few more to 3.0.0, my concern is Apache Lucene 10 (no date AFAIK):

scrawfor99 commented 5 months ago

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.

  1. Releasing 3.0 puts the project at risk for significant slippage

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?

  1. Foundation first

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.

  1. More support of breaking changes

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.

bbarani commented 5 months ago

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.

image

@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.

bbarani commented 5 months ago

@bbarani a few more to 3.0.0, my concern is Apache Lucene 10 (no date AFAIK):

Added these items to the 3.0 breaking changes list on this issue. CC: @reta

andrross commented 5 months ago

Regarding potential breaking changes for 3.0, here are a couple more:

bbarani commented 5 months ago

Regarding potential breaking changes for 3.0, here are a couple more:

Added these items to the 3.0 breaking changes list. CC: @andrross

AESthetix256 commented 5 months ago

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.

dblock commented 5 months ago

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.

tianleh commented 5 months ago

Add an OSD 3.0 breaking change https://github.com/opensearch-project/OpenSearch-Dashboards/issues/5639

Pallavi-AWS commented 5 months ago

Can the teams tagged with breaking changes evaluate if the changes are indeed breaking or can be done in a backward compatible manner?

elfisher commented 5 months ago

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)

CEHENKLE commented 5 months ago

Hey, I'm confused. In our docs we say about major versions:

In contrast, OpenSearch releases new major versions only when there are a critical mass of breaking changes (e.g. changes that are incompatible with existing APIs). These tend to be tied to Lucene major version releases, and will be announced in the forums at least 4 weeks prior to the release date.

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 :)

dblock commented 5 months ago

A big feature for 3.0 is HTTP/2 support. This is not possible without a breaking change. RestClient and RestHighLevelClient depend and expose Apache HttpClient 4.x APIs.

bbarani commented 5 months ago

A big feature for 3.0 is HTTP/2 support. This is not possible without a breaking change. RestClient and RestHighLevelClient depend and expose Apache HttpClient 4.x APIs.

Added it to the list.

bbarani commented 4 months ago

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.

peternied commented 4 months ago

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?

bbarani commented 4 months ago

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

bbarani commented 4 months ago

Closing this issue as we have finalized the 2024 release schedule for OpenSearch and the PR has been merged now.

AmiStrn commented 4 months ago

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.