-
Notifications
You must be signed in to change notification settings - Fork 16
Unmark suites and bump version to 24.2.1.1 #842
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
base: mandrel/24.2
Are you sure you want to change the base?
Conversation
@@ -4,8 +4,8 @@ | |||
"sourceinprojectwhitelist" : [], | |||
|
|||
"groupId" : "org.graalvm.compiler", | |||
"version" : "24.2.1.0", | |||
"release" : True, | |||
"version" : "24.2.1.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this is the script doing it, but we should probably change this to 24.2.2.0
over 24.2.1.1
. The July release will likely be 24.2.2.0-Final
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, we either bump straight to 24.2.2.0 and patch the version only if required to make a pre-CPU release or bump it to 24.2.1.1 now and bump it later to 24.2.2.0 (when merging upstream changes). The latter is what we have been doing so far. I am OK with either approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My thinking is that we haven't done any in-between-cpu releases in quite some time. So I'd rather go with the more likely approach and deal with the uncommon version update (24.2.1.x in the current case) asynchronously as needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no objections to changing the scheme as long as it keeps being automated in: https://github.com/graalvm/mandrel-packaging/blob/master/release-scripts/mandrel-release.java
Perhaps could be wrapped up in the change: graalvm/mandrel-packaging#490 because not having this automated essentially makes the JDK 21 suite.py changes a manual effort...
This PR appears to be stale because it has been open 30 days with no activity. This PR will be closed in 7 days unless |
This PR was automatically generated by
mandrel-release.java
of graalvm/mandrel-packaging!