-
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
[Retrospective] Release Version 2.2.0 #2451
Comments
Last-minute changes that were merged in core OpenSearch (1-2 days before code cutoff for plugins) caused unforeseen failures in both source code and test cases for plugins (example, example), where not all issues were able to be resolved by the code cutoff. Some were merged after the initial test builds were ready. This made it very difficult to plan for, and potentially could have delayed the release. I recommend core has a cutoff sooner than the plugins to prevent this, and give plugins some more buffer time to better handle situations like this. Additionally, dependent plugins + core (ref, ref) were not version bumped right after the latest release, and so our AD plugin couldn't test 2.2 compatibility until a few days before the code cutoff. I know this is the goal of infra team already, but it seems to not be enforced. But I believe the auto-version-increment campaigns should improve this for future releases. |
The build-tools where not published with the release. See Aiven-Open/prometheus-exporter-plugin-for-opensearch#87 |
Specifically regarding release notes: thank you for providing them early to the doc team! In the future, if the developers adhere to the PR naming guidelines, all of the bullet points in the release notes will have consistent verb forms and capitalization. This will avoid bullet points starting with different forms of the same verb like "Add", "adds", "Adding" and "added". |
Hi @lukas-vlcek We have opened an issue with Sonatype to resolve this issue. We will keep this thread updated with the current status |
Some code changes were merged in to 2.2.0 branch after RC build was finalized assuming it will be auto picked up to generate new RC build. We identified this change at the last minute and need a mechanism to prevent this from happening in future. |
@ohltyler We dont have plans to freeze core sooner than the cut-off time rather we would like to start the continuous integration process before the code-cutoff date to surface the issues mentioned here sooner. Would it help if we add an additional phase (CI on-boarding) to the release checklist prior to code cut-off? Every plugin team should have version specific branch created and on-boarded on to the manifest by then. CC: @CEHENKLE @dblock |
The existing checklist already has an entry that says "increment the version to next developer iteration", which automatically means that CI should be building on that next version. |
Thanks everyone for the feedback this retro is closed for now. |
#2271
How to use this issue?
Please add comments to this issue, they can be small or large in scope. Honest feedback is important to improve our processes, suggestions are also welcomed but not required.
What will happen to this issue post release?
There will be a discussion(s) about how the release went and how the next release can be improved. Then this ticket will be updated with the notes of that discussion along side action items.
The text was updated successfully, but these errors were encountered: