Skip to content
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

Fix bwcVersions after bumping version 1.3.1 #2532

Merged
merged 2 commits into from
Mar 21, 2022

Conversation

nknize
Copy link
Collaborator

@nknize nknize commented Mar 21, 2022

This version needed to be added after bumping 1.3 branch to 1.3.1 in #2509

Signed-off-by: Nicholas Walter Knize <nknize@apache.org>
@nknize nknize added v2.0.0 Version 2.0.0 non-issue bugs / unexpected behaviors that end up non issues; audit trail simple changes that aren't issues backwards-compatibility labels Mar 21, 2022
@nknize nknize requested a review from a team as a code owner March 21, 2022 17:42
@reta
Copy link
Collaborator

reta commented Mar 21, 2022

@nknize we need to add 1.3.1 to Version.java as well:

public static final Version V_1_3_1 = new Version(1030199, org.apache.lucene.util.Version.LUCENE_8_10_1);

Signed-off-by: Nicholas Walter Knize <nknize@apache.org>
@nknize
Copy link
Collaborator Author

nknize commented Mar 21, 2022

@nknize we need to add 1.3.1 to Version.java as well:

public static final Version V_1_3_1 = new Version(1030199, org.apache.lucene.util.Version.LUCENE_8_10_1);

I just saw that! Pushed the constant. thx!

@dblock
Copy link
Member

dblock commented Mar 21, 2022

Hopefully by next iteration the auto-increment workflow will kick in and work so we don't need to do this by hand.

@tlfeng
Copy link
Collaborator

tlfeng commented Mar 21, 2022

Not related to this PR, but a thought regarding adding new BWC version in main branch, after adding version in branches of lower versions.
The same negligence occurred just 10 days ago, and fixed by PR #2430. Maybe some documentation needs to be added, and remind people who adding new BWC version in branches other than main.
Update: just saw @dblock comment on above 😄. It's a good solution.

@dblock
Copy link
Member

dblock commented Mar 21, 2022

#2430

I think it wouldn't hurt to have a test that runs part of a gradle precommit / check that all these versions are in sync.

@opensearch-ci-bot
Copy link
Collaborator

❌   Gradle Check failure 4a14238
Log 3593

Reports 3593

@nknize
Copy link
Collaborator Author

nknize commented Mar 21, 2022

I think it wouldn't hurt to have a test that runs part of a gradle precommit / check that all these versions are in sync.

Sounds like a great first issue or something for the Infra / Build team to pick up!

@dblock
Copy link
Member

dblock commented Mar 21, 2022

I think it wouldn't hurt to have a test that runs part of a gradle precommit / check that all these versions are in sync.

Sounds like a great first issue or something for the Infra / Build team to pick up!

#2533

@opensearch-ci-bot
Copy link
Collaborator

✅   Gradle Check success 79edaaf
Log 3594

Reports 3594

@nknize nknize merged commit ce0d2ca into opensearch-project:main Mar 21, 2022
reta pushed a commit to reta/OpenSearch that referenced this pull request Mar 21, 2022
Signed-off-by: Nicholas Walter Knize <nknize@apache.org>
Signed-off-by: Andriy Redko <andriy.redko@aiven.io>
nknize added a commit that referenced this pull request Mar 21, 2022
Signed-off-by: Nicholas Walter Knize <nknize@apache.org>
Signed-off-by: Andriy Redko <andriy.redko@aiven.io>

Co-authored-by: Nick Knize <nknize@apache.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backwards-compatibility non-issue bugs / unexpected behaviors that end up non issues; audit trail simple changes that aren't issues v2.0.0 Version 2.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants