[Release 3.0] Bump 3.0.0 version with alpha qualifier (3.0.0-alpha)

[peterzhuamazon]

Description

[Release 3.0] Bump 3.0.0 version with alpha qualifier (3.0.0-alpha)
So we can test the new alpha version on Jenkins earlier and mitigate issues.

Related Issues

opensearch-project/opensearch-build#3747

Check List

• [ ] Functionality includes testing.
• [ ] API changes companion pull request created, if applicable.
• [ ] Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[reta]

@peterzhuamazon I believe we need to get #16366 in, as of today, the 3.0.0 is very far from what it should be.

[github-actions]

❕ Gradle check result for 4ed517d: UNSTABLE

Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 72.25%. Comparing base (f98f426) to head (4ed517d).
Report is 25 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##               main   #17020   +/-   ##
=========================================
  Coverage     72.24%   72.25%           
- Complexity    65305    65332   +27     
=========================================
  Files          5301     5301           
  Lines        303774   303774           
  Branches      44016    44016           
=========================================
+ Hits         219458   219479   +21     
- Misses        66272    66312   +40     
+ Partials      18044    17983   -61     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[peterzhuamazon]

Hi @reta this is more for testing the build pipelines beforehand.
Would you still recommend we wait until your PR is ready?
Or do you want to combine this change to your PR? Thanks.

[reta]

Hi @reta this is more for testing the build pipelines beforehand.

That @peterzhuamazon, here is the risk factor to keep in mind:

• if we change the version, we would stop publishing snapshots (3.0.0-SNAPSHOT)
• consequently, every single plugin out there would be using the last published snapshot, oblivious to any changes
• but we want plugin maintainers to actually level to up to 3.0.0 baseline

I think having a major chunk of changes (the PR in question) in would be a great milestone for version change. @andrross any thoughts on the subject?

[andrross]

@reta If we do the 3.0.0-alpha version change along with the Lucene 10 PR, then plugins will not immediately break on their main branch because they will still be consuming 3.0.0-snapshot which was the last commit before Lucene 10. They can then start integrating the major 3.0 changes at their own pace because they have to update to consume 3.0.0-alpha. Is that correct? That might actually be the best option to start merging the big changes in to core without being disruptive to the 2.19 release.

[reta]

That might actually be the best option to start merging the big changes in to core without being disruptive to the 2.19 release.

Thanks @andrross , I was thinking about it as well but didn't like it because it will fire back - no one will update to 3.0.0-alpha, it will be unnoticed till the last moment.

[andrross]

That might actually be the best option to start merging the big changes in to core without being disruptive to the 2.19 release.

Thanks @andrross , I was thinking about it as well but didn't like it because it will fire back - no one will update to 3.0.0-alpha, it will be unnoticed till the last moment.

@reta That's a risk, but I still think I like this approach. We can open the PRs against all the plugin repositories to update to the alpha version, and then ensure they get merged after the 2.19 release at the latest.

[reta]

That might actually be the best option to start merging the big changes in to core without being disruptive to the 2.19 release.

Thanks @andrross , I was thinking about it as well but didn't like it because it will fire back - no one will update to 3.0.0-alpha, it will be unnoticed till the last moment.

@reta That's a risk, but I still think I like this approach. We can open the PRs against all the plugin repositories to update to the alpha version, and then ensure they get merged after the 2.19 release at the latest.

Sure, thanks @andrross !

[dbwiddis]

@reta That's a risk, but I still think I like this approach. We can open the PRs against all the plugin repositories to update to the alpha version, and then ensure they get merged after the 2.19 release at the latest.

@andrross I like this.... open a PR, it will give plugin maintainers a roadmap on what to fix (if any).

One of my biggest concerns is deprecated method removal. And it may have been answered on another issue/PR, but I'll ask again here. We're supposed to have already migrated away from deprecated code (except ones that are impossible like AcknowledgedResopnse) but not everyone has, particularly around MediaType stuff. Nothing major but enough churn that it requires some attention. I don't mind doing that during alpha phase but would kind of like a timeline for "ok we're done with major changes when we flip from alpha to beta" or the like.

[andrross]

@dbwiddis The core release tracker is #16935. We don't have a solid date yet but we plan to have the major breaking changes done in core well before the first alpha release in order to give time for downstream repos to adapt.

[peterzhuamazon]

Hi @reta @andrross please feel free to approve this PR before the lucene10 one here:

• Update to Apache Lucene 10 for 3.0.0 #16366

Thanks!