-
Notifications
You must be signed in to change notification settings - Fork 277
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RELEASE] Release version 2.11.1 #4161
Comments
Bug fixes targeted for 2.11.1 release:OpenSearch: |
List of repos that have changes merged in to 2.11 branch post 2.11 release.
|
So we need to make a decision about 2.11.1. A little background first: 1/ We need this release because of a critical breaking bug in the security plug-in. This bug impacts everyone using logstash and the only work around is to turn off compression (which is expensive) 2/ As a refresher, our normal process is to commit changes to main, then backport to 2.x.. Since the 1.0 release, we only backport bug fixes and security changes to the current 2.x branch (in this case 2.11) so that if we need to we can quickly do a patch release we can. 3/ There are two reason we don’t back port features to the current release branch (right now 2.11): However, looking at the list of changes for 2.11, we currently have a mix of features that have been merged in. Here are the ways forward that we’ve thought of (feel free to suggest another way):
As you can see, there’s no solution without cons, but given all the trade-offs, I’m leaning towards 1. WDYT? Thanks, PS, because this is impacting people today, I’d like to get this release out ASAP. So please put your comments up in the next 48 hours so we can prep a release for early next week (if that's what we're going to do). I also want to better understand why features were backported to the release branch, and what we should do about this in the future, but I’d like to tackle that after 2.11.1 is out. |
Thanks @CEHENKLE
+1 to this option, for OpenSearch core at least, out of 3 merged pull requests, 2 are non-functional changes and 1 is a bugfix (with accordance to semver and signed off by the team before the merge). For a plugins though (except |
Regarding back-ported features in release branches
😶 That's unexpected. It feels like a lot of these backports PR where opened with some automation due to improper labels being put on the initial PR (i.e. a feature should only have been labeled Regarding what to do with the next release
Given the situation, 0 & 3 seems the most practical (bump minor version and release), 4 is probably the cleanest thing we can do but require more efforts (allows us to bump the patch version and release). Branching If the cost regarding community trust of releasing 2.12 earlier than announced and without the announced features of 2.12 seems problematic, scenario 4 is probably what must be done IMHO. If both are too much pain, as a last resort scenario 0 is acceptable. |
Chiming in for Security, I would advocate for option 1, as its the smallest deviation from our existing process and I trust that maintainers are making the right choices. For me the most important trait of following Semver is signaling breaking changes on major version changes, secondarily is signaling potential risk between minor/patch versions. The sematic argument of 'is it a feature or a bug' is hard to judge on a product of this scale. Changing the process mid-flight is risky - I'd advocate for doing a retro afterwards to drill into misaligned expectations around branches / release. |
I think that this should be the 2.12 release. We know there are features and bugs in this release. We need to be careful with testing and make sure we're confident in the release. It's a slippery slope to make exceptions on semver, but continue to say that we follow it. We should also have a retro meeting after the fact that involves representatives from interested parties who take these releases into their products/services. |
In terms of level of effort, options 2 and 4 seem comparable/equivalent, but 4 gets us to a proper/desired state where we'd prefer to be, whereas option 2 deviates our process quite a bit.
But we have evidence that's not the case - maintainers are responsible for adding the labels which triggers the backport automation and have (intentionally or not) violated semver by improperly backporting features to the 2.11 branch. |
I recommend rewinding all 2.11 to the 2.11 release, then applying only security fixes on top, aka reverting anything that's not a security fix from 2.11. If there were a critical security vulnerability right now we would have to do that. If we ship 2.11.1 with the additional commits we won't be able to do a 2.11.2 just with security fixes, forcing these features onto users who have standard practices around semver. At the same time, we can ship 2.12 with these features as always. |
.. and bugfixes (this fits semver), for OpenSearch core there was deliberate decision to bring the bugfix to 2.11.1 (see please Slack discussion in #release channel). |
@dblock you're endorsing option 4, correct? That is the best option in my opinion. If we ever have to do a 2.11.2, you would want 2.11.1 to be in the state that db is describing. |
I would agree - if we do a 2.11.1, it should follow Semver and only be bug fixes. Vote for option 4 - then we can move any feature-related work to 2.12 |
I also vote for option #4. I don't think that tossing semver is a good call and some of the changes seem pretty substantial. For example: opensearch-project/sql@6e17ae6 opensearch-project/security-analytics@658aa99 opensearch-project/security-analytics@559d97e None of these seem like bug fixes to me and we should not say we are semver if we are not. That leaves releasing 2.12 now or reverting changes. I don't think we should release now, since I doubt that will be easier than reverting and don't love having such a thin/rushed version. That leaves reverting as the best choice in my opinion. |
Okay, seems like we're coalescing around number 4 (Revert all feature related changes from 2.11 branch, release 2.11.1 from there). We'll put a meta issue up (linked here) with sub issues for each feature added, and track the removal here. When they're all closed, we'll cut the release. In the spirit of many eyes make shallow bugs, everyone feel free to cross check the issues ID'd in the meta issue once it's up to make sure we didn't miss anything. Thanks, |
Release Candidate details for OpenSearch - 8873 and OpenSearch Dashboards - 6816OpenSearch - Build 8873
Check how to install opensearch and dashboards on different platforms |
Final Release Candidate details for OpenSearch - 8875 and OpenSearch Dashboards - 6816OpenSearch - Build 8875
Check how to install opensearch and dashboards on different platforms |
Integration Test results for 2.11.1:For OpenSearch:x64 Tarball: https://build.ci.opensearch.org/blue/organizations/jenkins/integ-test/detail/integ-test/6514/pipeline Failed plugins:
arm64 Tarball: https://build.ci.opensearch.org/blue/organizations/jenkins/integ-test/detail/integ-test/6513/pipeline Failed plugins:
For OpenSearchDashBoards:Failed plugins:
Failed plugins:
|
We couldn't finalize a release candidate build for 2.11.1 release due to last minute issues in OSD along with missing release notes in multiple repositories. We have moved the release date for 2.11.1 to Nov 27 2023 to accommodate the fixes. Please let us know if you have any questions. |
I signoff dashboardsObservability plugin "with security" integ test - we have test manually with success. |
I signoff OpenSearch Dashboards integ tests - we have tested those manually and so success. We will do a quick follow to ensure test success on the official job. cc: @manasvinibs |
OpenSearch 2.11.1 Release ChecklistPre-Release activities
Release activities
Post-Release activities
|
All, Maven publishing part is delayed due to this issue. We will publish it to Maven as soon as the issue is fixed |
Hello all, we discovered that few enhancements were merged in to the final release candidate of 2.11.1 version deviating from SemVar guidelines. We have requested the maintainers of the repo to revert the changes. We have moved the 2.11.1 release to Nov 30 2023 to accommodate the changes. |
Awaiting for the merge of the revert PR's with features and enhancements before moving forward with the 2.11.1 release |
Final Release Candidate details for OpenSearch - 8933 and OpenSearch Dashboards - 6867OpenSearch - Build 8933
Check how to install opensearch and dashboards on different platforms |
Integration Test results for 2.11.1:For OpenSearch - 8933:x64 Tarball: https://build.ci.opensearch.org/blue/organizations/jenkins/integ-test/detail/integ-test/6515/pipeline arm64 Tarball: https://build.ci.opensearch.org/blue/organizations/jenkins/integ-test/detail/integ-test/6516/pipeline All components integration tests are passing for OpenSearch For OpenSearchDashBoards - 6867:Failed plugins:
Check the test-report manifest in the issue for logs related to OSD integ-test failure Failed plugins:
Check the test-report manifest in the issue for logs related to OSD integ-test failure |
Manual sign off on those tests. Currently working on it: opensearch-project/OpenSearch-Dashboards#5506 |
Final Release Candidate details for OpenSearch - 8942 and OpenSearch Dashboards - 6867OpenSearch - Build 8942
Check how to install opensearch and dashboards on different platforms |
Integration Test results for 2.11.1:For OpenSearch - 8942:x64 Tarball: https://build.ci.opensearch.org/blue/organizations/jenkins/integ-test/detail/integ-test/6524/pipeline All components integration tests are passing for OpenSearch For OpenSearchDashBoards - 6867:Failed plugins:
Check the test-report manifest in the issue for logs related to OSD integ-test failure Failed plugins:
Check the test-report manifest in the issue for logs related to OSD integ-test failure |
Validated signatures:
|
Native Plugin Installation:
|
OpenSearch 2.11.1 version has been released 🎉 ! |
Release OpenSearch and OpenSearch Dashboards 2.11.1
I noticed that a manifest was automatically created in manifests/2.11.1. Please follow the following checklist to make a release.
How to use this issue
This Release Issue
This issue captures the state of the OpenSearch release, its assignee (Release Manager) is responsible for driving the release. Please contact them or @mention them on this issue for help. There are linked issues on components of the release where individual components can be tracked. For more information check the the Release Process OpenSearch Guide.
Please refer to the following link for the release version dates: Release Schedule and Maintenance Policy.
Preparation
Campaigns
Release Branch and Version Increment - Ends Nov 14 2023
Feature Freeze
Code Complete - Ends date
Release Candidate Creation and Testing - Ends Nov 21 2023
Pre Release - Ends Nov 24 2023
Release - Ends Nov 27 2023
Release Checklist.
Release Checklist
Pre-Release activities
Release activities
Completed validation for <>
in the logs).Post-Release activities
Post Release
Components
Replace with links to all component tracking issues.
Legend
The text was updated successfully, but these errors were encountered: