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

[1.3.z] Update release checker #1211

Merged

Conversation

gtroitsk
Copy link
Member

@gtroitsk gtroitsk commented Jul 19, 2024

Summary

Backports #1202 and #1209

Please check the relevant options

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Dependency update
  • Refactoring
  • Backport
  • Release (follows conventions described in the RELEASE.md)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • This change requires a documentation update
  • This change requires execution against OCP (use run tests phrase in comment)

Checklist:

  • Example scenarios has been updated / added
  • Methods and classes used in PR scenarios are meaningful
  • Commits are well encapsulated and follow the best practices

(cherry picked from commit c003bcf)
@gtroitsk
Copy link
Member Author

gtroitsk commented Jul 19, 2024

@michalvavrik release check failure is expected as we already have similar release 1.3.1.Final, script recognized it as 1.3.1. I don't like to release 1.3.2 as it will not contain any changes for RHBQ.

@michalvavrik
Copy link
Member

@michalvavrik release check failure is expected as we already have similar release 1.3.1.Final, script recognized it as 1.3.1. I don't like to release 1.3.2 as it will not contain any changes for RHBQ.

Won't this PR trigger the release flow which will fail because you create PR from your fork? TBH I'd prefer to actually make release so that next guy that comes after you can just increment by one. This way, we have this whole compatibility issues behind us.

@gtroitsk
Copy link
Member Author

@michalvavrik release check failure is expected as we already have similar release 1.3.1.Final, script recognized it as 1.3.1. I don't like to release 1.3.2 as it will not contain any changes for RHBQ.

Won't this PR trigger the release flow which will fail because you create PR from your fork? TBH I'd prefer to actually make release so that next guy that comes after you can just increment by one. This way, we have this whole compatibility issues behind us.

I create another PR with release after this PR will be merged. So, 1.3.2 may be the next?

@gtroitsk gtroitsk force-pushed the backport/1.3.update-release-checker branch from ef6efa2 to aa70e19 Compare July 19, 2024 09:33
@michalvavrik
Copy link
Member

I create another PR with release after this PR will be merged. So, 1.3.2 may be the next?

sounds good

Copy link
Member

@michalvavrik michalvavrik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@michalvavrik michalvavrik merged commit fd62eb9 into quarkus-qe:1.3.z Jul 19, 2024
1 check failed
@gtroitsk gtroitsk deleted the backport/1.3.update-release-checker branch July 19, 2024 10:57
@gtroitsk gtroitsk mentioned this pull request Sep 9, 2024
11 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants