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

Update Gradle wrapper to Gradle 8.14 (milestone 5) #129

Merged
merged 1 commit into from
Mar 23, 2025

Conversation

msgilligan
Copy link
Member

No description provided.

# Conflicts:
#	gradle/wrapper/gradle-wrapper.properties
@msgilligan msgilligan force-pushed the msgilligan/gradle-8.14 branch from 664ce06 to 23e5bfa Compare March 20, 2025 21:29
@msgilligan msgilligan changed the title Update Gradle wrapper to Gradle 8.14 (snapshot) Update Gradle wrapper to Gradle 8.14 (milestone 5) Mar 20, 2025
@msgilligan msgilligan marked this pull request as ready for review March 20, 2025 21:41
@msgilligan
Copy link
Member Author

msgilligan commented Mar 20, 2025

I'm ready to merge this PR to master. I would like to begin experimenting with JDK 24 on some branches and feel it will be ok to use a pre-release Gradle on master. This PR does not change requirements for the build or for using the JARs, just upgrades the Gradle wrapper to 8.14-milestone-5. You can always build with an earlier version of Gradle.

The next release of secp-jdk will be v0.2 and Gradle 8.14 will almost certainly be final before then. So, given that the risk is low, that this project is still pre-alpha, and we can always back it out if we really need to, I think it is reasonable to use this (5th) milestone release of Gradle on master.

I also plan to submit PRs as soon as RC builds of Gradle 8.14 are available.

Sound OK @schildbach and @craigraw ?

Copy link
Member

@schildbach schildbach left a comment

Choose a reason for hiding this comment

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

What I usually do in such cases is keep the commit as part of the experimental branches. Git makes this super easy to manage (rebase, cherry-pick, etc). Using a pre-release of Gradle bears the risk of regression, which can affect all devs, also those not running experiments with Java 24.

I leave the decision up to you. The PR itself looks good.

@msgilligan msgilligan added this to the Version 0.2 (was 0.0.3) milestone Mar 22, 2025
@msgilligan
Copy link
Member Author

What I usually do in such cases is keep the commit as part of the experimental branches. Git makes this super easy to manage (rebase, cherry-pick, etc).

Good point, and I would normally do this.

Using a pre-release of Gradle bears the risk of regression, which can affect all devs, also those not running experiments with Java 24

Since this is only the wrapper, it will only affect builds of this project for those using the wrapper.

I leave the decision up to you. The PR itself looks good.

I feel the risks of regression is fairly low and I'd like to move towards JDK 24 ASAP -- for the build and examples (but not the libraries) and JDK 25 as soon as it is ready. We can stabilize on 25. I'm hoping (with little knowledge of the details) that the JEP 484: Class-File APIwill make it easier for Gradle to support new JDK releases.

I'm going to go merge it and keep my fingers crossed -- I think we'll be fine.

@msgilligan msgilligan merged commit af45d7d into master Mar 23, 2025
14 checks passed
@msgilligan msgilligan deleted the msgilligan/gradle-8.14 branch March 23, 2025 00:37
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.

3 participants