Further build file improvements #201
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "further-build-file-improvements"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Don't want to install a new SDK version now, so I'm leaving this PR for later.
FYI, replacing the Gradle wrapper is a suspicious action. Although I believe you're genuinely trying to help and the JAR checksum seems good, Gradle doesn't seem to provide a way to verify the scripts, so it'll still be more difficult to review a PR than upgrading myself.
That's fair, which is why I linked to https://docs.gradle.org/current/userguide/gradle_wrapper.html#wrapper_checksum_verification on that commit.
However I do know that there's a Github action to check the gradle wrapper: https://github.com/marketplace/actions/build-with-gradle#the-wrapper-validation-action
If you think it's best, I can just remove the Gradle update commit and you can do it on your own in a future point in time.
That's true, though from the diff it seems that barely anything changed. Mostly changes on how the gradle wrapper is invoked and formatting changes.
For now I just rebased the branch so I could remove the commit about updating Gradle.
Please consider upgrading to Gradle 9 at your earliest convenience if your project isn't incompatible!
Done. But why is that an urgent matter? Is there some vulnerability I don't know of?
You have a point. It's not as much that it's urgent or that there's a important patched vulnerability.
It's more on the nature that this project is in maintenance mode but still receiving PRs.
It's feature complete enough to not really need updates constantly, but if it goes, for example, some 3 months or more without any changes, then it would be nice if I at least it was somewhat "modern" enough (on relation to how is built) compared to what was available at the time.
Tbf that's some of my logic on how I handle dependencies or tooling/SDKs on my own projects, I try to be as modern as it makes sense at that point in time.