[PROPOSAL] OpenSearch Release Schedule for Year 2025

[peterzhuamazon]

Hi All,

We are happy to share the newly proposed Release Schedule for OpenSearch Project in 2025!

After discussions and feedback based on these given issues, we would like to share it with the community for review.

• [PROPOSAL] Change OpenSearch release cadence for 2025 #234
• [PROPOSAL] Release OpenSearch 3.0 #250
• [PROPOSAL] Simplify OpenSearch distribution branching strategy #251

### 2025 Release Schedule (Rev2 20250110, pending feedback)

Release Version	First RC Generated (release window opens)	Latest Possible Release Date (release window closes)
2.19.0	1/28/2025	2/11/2025
3.0.0-alpha1	3/4/2025	3/18/2025
3.0.0-beta1	4/1/2025	4/8/2025
2.19.1	4/8/2025	4/15/2025
3.0.0 (GA)	4/22/2025	4/29/2025
3.1.0	6/10/2025	6/24/2025
2.19.2	7/15/2025	7/22/2025
3.2.0	8/5/2025	8/19/2025
3.3.0	9/30/2025	10/14/2025
2.19.3	10/28/2025	11/4/2025
3.4.0	12/2/2025	12/16/2025
3.5.0	1/27/2026	2/10/2026

### 2025 Release Schedule (20241219)

Release Version	First RC Generated (release window opens)	Latest Possible Release Date (release window closes)
2.19.0	1/28/2025	2/11/2025
3.0.0-alpha	2/17/2025	3/17/2025
3.0.0-beta	3/24/2025	3/31/2025
3.0.0 (GA)	4/1/2025	4/8/2025
3.1.0	5/20/2025	6/3/2025
2.19.1	6/17/2025	6/24/2025
3.2.0	7/15/2025	7/29/2025
3.3.0	9/9/2025	9/23/2025
2.19.2	10/14/2025	10/21/2025
3.4.0	11/4/2025	11/18/2025
3.5.0	1/27/2026	2/10/2026

Highlights

• 1.3.x Deprecation: Support for the 1.3.x version will end in 2025.
• 2.19.x Maintenance Mode: The 2.19.x version will enter maintenance mode, with patch version released between every two 3.x releases with a quarterly release schedule.
• 3.x Major Release: The 3.0.0 major version will be released alongside Lucene 10. We will release minor updates for the 3.x line follows a 8-week cadence.

We believe this schedule will allow us to deliver high-quality updates while maintaining a predictable cadence for the community. Additionally, it provides the team with more time to fine-tune releases and improve their overall quality.

This will also address issues like overlapping release windows, reduce the strain on the infra team, and give feature teams more time to complete significant features without frequent interruptions.

Please share your feedback in the comments.

Thanks!

[peterzhuamazon]

cc: @getsaurabh02 @andrross @dblock @msfroh @krisfreedain @nateynateynate @kolchfa-aws

Thanks!

[peterzhuamazon]

20241220 Update:

• Move 3.0.0 GA back to 04/08/2025 release date, move alpha and beta dates back.
• Tweak 2.19.1 and 2.19.2 dates based on 3.0.0 new dates.
• Increase one more release for 3.x.

[dblock]

[Catch All Triage - 1, 2, 3, 4, 5, 6]

[peterzhuamazon]

We will make a new PR tomorrow on this schedule to our website.

Thanks.

[dbwiddis]

I'm a bit concerned about the timeline here, given some anecdotal conversations that I've had.

1. More than half the people I've mentioned this to have not even heard about it. While the original proposal is 3 weeks old, it was posted on Dec 19, and many in the community have not been as active over the past couple of weeks due to the holiday season. I would respectfully request at least a few more days' delay to consider feedback from a lot of folks who are just re-engaging this week.

2. 2.19.0 is going to be a more significant release given the longer time period since 2.18.0 and there is a lot more effort being spent until end-of-January preparing for that. I'm on the fence on whether a major release RC only a few weeks after that is a good idea, which depends on whether main is "stable" across all plugins. Given how frequently main gets broken with various backwards incompatible changes, I would like to see more detail on what "alpha", "beta", and "GA" mean in terms of how much effort downstream dependencies (I'm specifically referring to plugins who often need time to react to incompatible changes in core) will need to expend to "fix" broken builds.

   • Specifically: will main begin tracking 4.0.0-SNAPSHOT and existing main become 3.x? On which date? Or is main going to be a constantly potentially changing target? I see some discussion in [PROPOSAL] Simplify OpenSearch distribution branching strategy #251 but no resolution or clear direction for what plugins should expect. I'd really like to see some closure on that discussion before we commit to a schedule, so plugins can have clear guidelines on when their upstream dependency will be frozen for incompatible changes.

TLDR: I expect a lot of things to break and just looking at this timeline without additional details on "incompatible change code freeze" dates really concerns me.

[kkhatua]

I see your point on this, but the release train model is driven by schedule and features should ideally either hop on a train or catch the next release. That has been the motivation behind 2024 having a 6 week cadence between each release... which is being proposed to be 8 weeks to relieve some stress doing back to back releases.
Regarding your primary question, I'm guessing 3.0.0-alpha is when 3.x is cut, and that is when main will track 4.0.0-SNAPSHOT.

[dbwiddis]

features should ideally either hop on a train or catch the next release.

Agreed 100%. The point here is that it's not clear when the train is leaving the station. We have had multiple instances in the last year where incompatible changes were merged to main within weeks prior to a release. Sure, they weren't meant to be backported to 2.x and that is exactly the point.

Discussion on #251 indicates there may not be a separate 3.x branch. It hasn't been concluded. As a plugin maintainer I want to have clear expectations of whether the main now is frozen for incompatible changes (that plugins need to change code for) or, if not, on exactly what date that will be.

[krisfreedain]

@andrross - can you provide input - we may need to cover with the TSC as well. Thanks

[peterzhuamazon]

Hi @dbwiddis ,

I will open the website PR on schedule change today and wait until next week for merge.

Thanks.

[peterzhuamazon]

Schedule PR here, will wait for a week for more feedbacks:

• Update release schedule for year 2025 project-website#3531

cc: @anastead @Pallavi-AWS @getsaurabh02 @andrross @dblock @msfroh @krisfreedain @nateynateynate @kolchfa-aws @dbwiddis @kkhatua @xinlamzn @seraphjiang @xluo-aws @reta

[dbwiddis]

Thanks!

Conversation on #251 reminded me of handling deprecated code.

There is a lot of deprecated code currently in main. My experience in most projects is that many/most of these deprecated methods get removed on a major version bump. Are we planning to do that?

[peterzhuamazon]

Next to follow:

• Stop 1.x release issue create and scan.

[xluo-aws]

Do we know how many PRs have been merged to main but not backported to 2.x?

[reta]

For a visibility, we've been discussing on TCS meeting if the Lucene 10 upgrade [1] needs to be on hold till 2.19.0 release kicks in (in order to not incur additional work on plugin maintainers and prevent backport / forward ports fest if possible). This is still in discussion but if happens to be so, the 3.0.0 schedule would have to be moved (to be updated).

[1] opensearch-project/OpenSearch#16366

[shwetathareja]

+1 to @dbwiddis here that without list of final breaking changes, the timelines for OpenSearch 3.0 (April, 2025) looks very aggressive. This will not give enough headroom for anyone (including plugins) to make appropriate client application changes or cloud providers to cater to the breaking changes smoothly.