Dependency updates for v2026.4#7302
Conversation
2cc3e33 to
d270ca8
Compare
9e0e567 to
2a41a2c
Compare
2a41a2c to
fb26935
Compare
| @@ -0,0 +1 @@ | |||
| sdk=33 | |||
There was a problem hiding this comment.
We should probably bump the Robolectric target SDK up right?
| @@ -1,70 +1,73 @@ | |||
| # After changing any version here, regenerate the dependency lockfile | |||
There was a problem hiding this comment.
What happens if I change a version or add a dependency without running --write-locks? I think a comment here is going to be very easy to miss: it's a long file, and you can scroll past or even just never see it if navigation from a linked definition. I'm thinking we really need an automated check for this.
There was a problem hiding this comment.
If you change or add a dependency without updating the lockfile, the build fails, so it's not possible to miss it.
| import java.util.concurrent.ConcurrentHashMap | ||
| import java.util.concurrent.TimeUnit | ||
|
|
||
| if (!project.hasProperty("runDependencyUpdates")) { |
There was a problem hiding this comment.
Why do we check for this? This isn't something that would change dynamically right?
| if (!project.hasProperty("runDependencyUpdates")) { | ||
| tasks.register("dependencyUpdates", Exec) { | ||
| def gradlew = System.getProperty("os.name").toLowerCase().contains("windows") ? "gradlew.bat" : "./gradlew" | ||
| commandLine gradlew, "dependencyUpdates", "--no-parallel", "-PrunDependencyUpdates=true" |
There was a problem hiding this comment.
Do we really need to call back to gradlew through commandLine here to execute these tasks? I think if we just want an alias we can just add a bash script right?
|
|
||
| if (!project.hasProperty("runDependencyUpdates")) { | ||
| tasks.register("dependencyUpdates", Exec) { | ||
| def gradlew = System.getProperty("os.name").toLowerCase().contains("windows") ? "gradlew.bat" : "./gradlew" |
There was a problem hiding this comment.
I kind of think we should ditch the Windows dev support stuff if I'm being honest. No one is looking at it, and I don't think it's worth the effort for us to care about.
| return stableKeyword || version ==~ /^[0-9.v-]+(-r)?$/ | ||
| } | ||
|
|
||
| def ageCache = new ConcurrentHashMap() |
There was a problem hiding this comment.
Is this just there to save on network calls for repeated dependencies?
There was a problem hiding this comment.
Yes, and it's a big saving in practice.
a32cc73 to
a28e8c3
Compare
2 participants
Why is this the best possible solution? Were any other approaches considered?
As usual, I've updated the dependencies for the next release. Things worth mentioning:
./gradlew dependencyUpdatesnow reports available updates, but only for stable versions that are at least 14 days old. Note this doesn't fail, or block builds if a newer version is used, it's purely a report/suggestion.collect_app/gradle.lockfilenow pins the exact resolved dependency versions for the debug and all release variants, preventing unintended transitive or dynamic version changes from silently affecting builds.ktlint-gradleplugin had stopped linting Kotlin sources in Android modules, making it effectively a no-op. Upgrading to version 14.2.0 restored linting and surfaced a number of violations, which were fixed as part of this change.How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
No need to test anything here.
Do we need any specific form for testing your changes? If so, please attach one.
No.
Does this change require updates to documentation? If so, please file an issue here and include the link below.
No.
Before submitting this PR, please make sure you have:
./gradlew connectedAndroidTest(or./gradlew testLab) and confirmed all checks still passDateFormatsTest