Repository navigation
[Proposal] Move the OpenSearch 2.12.0 release to Feb 20 2024 #4290
Description
Activity
- changed the title
[-][Proposal] Move the OpenSearch 2.12 release to Feb 20 2024[/-][+][Proposal] Move the OpenSearch 2.12.0 release to Feb 20 2024[/+]on Dec 15, 2023 The code freeze date for OpenSearch 2.12.0 release is currently set to Jan 09 2024 with release date schedule for Jan 23 2024. We are proposing to move the code freeze date for OpenSearch 2.12.0 release to Feb 06 2024 with release date set to Feb 20 2024.
what do we need to do to make this a reality? @bbarani
Agree @macohen - good suggestion.
No objection to postponing this. 1 month is not significant, especially with the proposed critical bug fixes.
Does anyone have any downside to this?
I see that many items would anyway be moving to 2.13 at this rate.
@deshsidd regarding the postponing of phase 1 of your PR -> what is your opinion on the proposed release date?Do we have a decision here? Is the release date moved?
Any update on this?
16 remaining items
Folks,
Thank you for warning us about the delayed release until Feb 20. In the future, I would object to all releases that are delayed without sufficient voice from non-AWS contributors.
I do agree that we want to have a stable release. That said, it seems that AWS needs and timelines seem to be prioritized over others.
We at Aryn have been waiting for the conversational memory and RAG features to move from experimental to GA. That is supposed to happen in 2.12 and our customers are waiting for that. The 1 month delay is critical for us.
Sorry to reopen, but I had a thought: We could hold the 2.12.0 of Jan 23rd, and then pull in the 2.13.0 by 2 weeks so it's a 4 week cadence rather than a 6 week.
Pros:
- It gets out features faster, and biases towards releasing rather than not releasing.
- We don't have a long(er) delay between releases, which reduces the risk of large merge conflicts
- It stays truer to the spirit of a release train model -- we go when we go.
- It puts some distance between two large changes (Lucene and JDK) if we split them up between 2.12 and 2.13
Cons:
- 4 weeks is tight for the team to release, but (IMHO as someone who's not doing the release, so take this with a boulder-sized grain of salt) is doable. We could move out the 1.3.x release to make some room and take some pressure off the team.
Thoughts?
Thanks @CEHENKLE !
We're in favor for keeping the 2.12.0 to Jan 23rd. We're also in favor for bringing in the 2.13.0 in by 2 weeks, to have a 4 week cadence.
Pros:
- We're moving faster as a project.
- We more firmly establish a "catch the train" model for releases. Community has more confidence in the release dates.
- Each release is more manageable.
Cons:
- Shorter timeline for AWS team and a revert from what was decided earlier.
@CEHENKLE @mashah we need to account time to upgrade to JDK21 for vector and core performance improvements and Lucene 9.9.1 for critical bug fixes in 2.12. We are currently working through both these upgrades. After the release calendar was updated with the new date, the community and repo teams have been planning with the new date. We can certainly improve the process for release date changes going forward (we can have a separate discussion on an improved process).
Thanks, @Pallavi-AWS for the follow up. Given you want more calendar time to work on 9.9.1, wouldn't it make sense to release what we have now at the planned time at the end of Jan, and then follow up in Feb with the critical fixes?
Thanks,
/CFor the record, Lucene 9.9.1 was just merged into
main: opensearch-project/OpenSearch#11421Sure enough, the automatic backport to 2.x failed, but @mch2 said that resolving it should be smooth.
Reacted by Pallavi and Huan JiangReacted by Andriy Redko@CEHENKLE Lucene 9.9.1 fixes memory leak bugs, which we have been waiting for. The work needed to upgrade is in-flight. Additionally, JDK21 provides a range of significant performance improvements, including vector search where OpenSearch is seeing rapid adoption.
Reacted by Andriy Redko, Huan Jiang, shwetathareja and Mohit Godwani@mashah @CEHENKLE The changes to support Lucene 9.9.1 and JDK21 seems to have already merged in to 2.x line across all repositories and reverting it might not be a straightforward process at this point in time. Also, as mentioned by @Pallavi-AWS, Lucene 9.9.1 fixes memory leak bugs, which we have been waiting for. The work needed to upgrade is in-flight. Additionally, JDK21 provides a range of significant performance improvements, including vector search. Having said that, are you ok with the proposed release date of Feb 20 2024 OR do we need to debate this further? We should take the decision by Jan 16 2024 to avoid any further delays. CC: @macohen @reta @elfisher
Reacted by Andriy Redko and Pallavi@bbarani I think the best thing we can take out of this is to revisit it in the retro how we make decisions and make changes going forward, but untangling things technically is probably more expensive that we can afford now. So I am okay with closing this and executing as planned.
Reacted by Barani and Pallavi
Is your feature request related to a problem? Please describe
OpenSearch 2.12.0 release is currently scheduled to be released on Jan 23 2024. We are proposing to move the release date of OpenSearch 2.12.0 version to Feb 20 2024 to accommodate the below action items,
Describe the solution you'd like
The code freeze date for OpenSearch 2.12.0 release is currently set to Jan 09 2024 with release date schedule for Jan 23 2024. We are proposing to move the code freeze date for OpenSearch 2.12.0 release to Feb 06 2024 with release date set to Feb 20 2024.
This proposal will help the team to upgrade, test OpenSearch Lucene version to 9.9.1 along with the JDK21 thoroughly in 2.12.0 version. Also, the additional time would allow the teams to close the flaky tests before the 2.12.0 release which would help in improving the quality of OpenSearch artifacts.
Describe alternatives you've considered
Keep the release date for 2.12.0 version as planned.
Additional context
No response