We now support only Gradle 8+. Use Gradle 8+ or stick to version 0.60.3 if you can’t yet.
+Update the priority of artifact version key rules so that the longest match takes precedence, rather than the final key length.
+That should fix the keys of androidx.wear.compose libraries.
Fix a bug where version keys would be marked as unused in some projects.
+Some version keys were wrongly marked as unused following version 0.60.0. That’s now fixed. +Thanks to the reporters and people that helped in reproducing the issue!
+Several Accompanist libraries were deprecated following this announcement. +As a result, we updated removed them from refreshVersions. +As usual, it won’t break projects because we update the dependency notations with the equivalent string literal. +Also, relevant inline comments with links will be added to assist migration.
+refreshVersions task¶Now, running the refreshVersions task repeatedly will be much faster, because it now supports
+configuration cache fully! That also means that it’s ready for Gradle 9 when it’ll be released.
refreshVersions configured for the buildSrc too.buildSrc too, a log would claim that new files were created after running the refreshVersions task, when they were only modified, or not touched at all. We fixed it.refreshVersions task, there would still be a log saying that versions.properties and libs.versions.toml (if any) were updated or created. Now, it’s only shown if there are actual changes.refreshVersions task, it would always claim that some versions were hardcoded as it counted project dependencies. We are now filtering those out, and we updated the wording to reflect that they might not be actually hardcoded, as is the case when versions come from a Gradle plugin.Yesterday, Google released a BoM for Jetpack Compose. +Today we’re introducing first-class support for it.
+To take advantage of it, you just need to add the dependency on platform(AndroidX.compose.bom).
+Just like Firebase.bom, make sure you add it before any dependent dependency:
dependencies {
+ implementation(platform(AndroidX.compose.bom)) // Add this FIRST
+ implementation(AndroidX.compose.material3) // Related dependencies AFTER
+ implementation(AndroidX.compose.material3.windowSizeClass) // Same as above
+}
+In case you need to use a pre-release version (alpha, beta, rc…), use the withVersionPlaceholder() function as such:
dependencies {
+ implementation(platform(AndroidX.compose.bom)) // Enables the BoM and depends on it
+ implementation(AndroidX.compose.icons.extended) // Uses version defined in the BoM
+ implementation(AndroidX.compose.material3.withVersionPlaceholder()) // Separate version in versions.properties
+}
+// Add Jetpack Compose to a project in seconds with refreshVersions.
+// NEW: The Compose BoM released on Android Dev Summit is supported!
+
+// No need to search for the versions, refreshVersions will do it for you!
+// It will add the latest most stable version, and will even add the updates
+// as comments in the versions.properties file (auto-created on first use).
+
+android {
+ buildFeatures.compose = true
+ composeOptions {
+ // Version and updates are in versions.properties
+ kotlinCompilerExtensionVersion = versionFor(AndroidX.compose.compiler)
+ }
+}
+
+dependencies {
+ // Version and updates of the BoM are in versions.properties too.
+ implementation(platform(AndroidX.compose.bom)) // Enables the BoM automatically
+ implementation(AndroidX.compose.runtime) // Version from the BoM
+ implementation(AndroidX.compose.icons.extended) // Version from the BoM
+
+ // What if you need a specific alpha/beta/rc version?
+ // withVersionPlaceholder() detaches the dependency from the BoM.
+ // Version and updates will therefore be in versions.properties
+ implementation(AndroidX.compose.material3.withVersionPlaceholder()) // Not from BoM
+}
+Since last changes in the Version class, versions like 1.7.20-RC and 1.7.20-Beta would be marked as stable instead of respectively ReleaseCandidate and Beta because the logic expected a number in all cases.
+The number is now optional for all pre-versions, except milestones.
+To prevent future recurrence of such regression, this commit +also adds tests that assert the expected stability level of +many known versions from various libraries.
+Disable the old refreshVersionsDependenciesMapping and migrateToRefreshVersionsDependenciesConstants Gradle tasks.
versionFor could not work as it should have if it was used in multiple modules with different values: the refreshVersions task would only display the updates of some of them, and mark the other ones as unused. This has been fixed.refreshVersionsCleanup task would log that the gradle/libs.versions.toml file was modified even if it wasn’t, and didn’t exist in the first place. This is now fixed.Thanks to all the folks that contributed in this release!
+ +Versions Catalogs are Gradle 7.4+ solution for storing dependencies and versions in a centralized file.
+Gradle will automatically recognize the gradle/libs.versions.toml file… and so will refreshVersions!
It is similar in spirit to the versions.properties file, and we are happy to add support for it:
./gradlew refreshVersions will now add available updates as comments inside the gradle/libs.versions.toml file../gradlew refreshVersionsMigrate --mode=VersionCatalogAndVersionProperties will generate a versions catalog and migrate your build to use it if you don’t have one already.Currently, we only support the default versions catalog. If you need support for multiple versions catalogs, add your 👍 on this issue.
+This is a big and new feature, so feel free to provide feedback in this thread, and report issues with the right info if there’s no existing one here.
+versionFor, and Jetpack Compose!¶versionFor was helpful when you need to access a version located in the versions.properties file, but if there was no dependency using it, you’d never see any updates.
+For projects/modules using Jetpack Compose from Google, that meant you’d never see any updates for the compiler, and you’d need to look it up yourself.
+Also, the version entry would be marked as unused, or would be the wrong one if you shared it with other Compose artifacts since the compiler now has its own versioning track.
Now, passing a dependency notation such as AndroidX.compose.compiler to versionFor is exactly the same as if you used the dependency somewhere in the project:
You’ll get all the updates, and if the version is not yet specified in the versions.properties file, as usual, refreshVersions will try to find the latest most stable version available, plus it will also add the available comments for any newer, less stable version.
+That makes it even easier to start a project with Jetpack Compose!
With this in a build.gradle.kts file:
android {
+ composeOptions {
+ kotlinCompilerExtensionVersion = versionFor(AndroidX.compose.compiler) // Kotlin DSL
+ kotlinCompilerExtensionVersion = versionFor(project, AndroidX.compose.compiler) // Groovy DSL
+ }
+}
+AndroidX.compose.compiler is equivalent to "androidx.compose.compiler:compiler:_".
You’ll get that in the versions.properties file if you were on version 1.3.0-rc01:
version.androidx.compose.compiler=1.3.0-rc01
+## # available=1.3.0-rc02
+## # available=1.3.0
+To make it easy to start new projects, new modules, or using a common library, we spent a lot of time adding built-in dependency notations for Kotlin, kotlinx, AndroidX, and more.
+However, it wasn’t so easy to know that they exist. +That’s why we made a dedicated page where you can find them all! Let us know how helpful it is to you!
+rejectVersionIf { … } had an issue: its removal would not be taken into account until the Gradle daemon would be killed. This now behaves correctly.pluginManagement { … }, which might have led to Gradle plugin updates being missed by refreshVersions. Now, we look up these repositories as well.Thanks to all the folks that contributed in updating the built-in dependency notations!
+CashApp.moleculeGoogle.accompanistGoogle.horologist and Square.okHttp3KtorJetBrains.exposed, Testing.assertj, Testing.hamcrestSpring.boms.springCloudKotlinX.multik, KotlinX.lincheck, KotlinX.deeplearningArrowAnd thanks to the GitHub sponsors of the maintainers Louis CAD and Jean-Michel Fayard who didn’t count the hours spent on this project since 2018-2019!
+We hope you save a lot of time thanks to this project and can therefore leave work early, or pursue more valuable tasks and projects. 😉
+If you’re not a sponsor yet, please consider becoming one, as a company, as an individual, or even both, it means a lot to us! +Just click the heart button at the top of the GitHub repo webpage, follow the steps, and your heart. Thank you!
+AndroidX.wear.tiles.material dependency notation that was pointing to wrong coordinates because of a typo.
+The test that was designed to catch this has been fixed to prevent future recurrence.Thanks to @yacine-ser for raising this memory leak issue along with a hint on the culprit, it was very helpful in reproducing and fixing the leak.
+refreshVersions task twice in a row with configuration cache enabled, the second run would fail, even in warning mode. It’s now fixed.GcsClient, and we’re very happy with that because it also has the benefit of reducing the total size of refreshVersions when we include its dependencies. Note that this is using internal Gradle APIs, but we’ve seen that they didn’t change in 5 years, and the code path is executed only if you have gcs backed repositories in your project.Thanks to Mike Gray for the contribution in adding ReactiveX, RxBinding, and RxRelay dependency notations!
+refreshVersions task itself is not compatible with configuration cache because it’s impossible with the current Gradle APIs.refreshVersions task will no longer fail if there’s a problem getting versions from a repository. Now, it will add contextual comments in the versions.properties file, so you know what failed, and don’t get fully blocked next time jcenter or another repository undergoes an outage. This should also help if you’re running the refreshVersions task through an unstable internet connection and some network calls fail because of that.Thanks to Kamalesh for the contribution in adding dependency notations!
+Dispatchers.shutdown()). We believe it caused memory leaks in the Gradle Daemon, and this change, made possible since kotlinx.coroutines 1.6.0 should fix the last memory leak cause.androidx.test family started diverging, so we changed replaced the version.androidx.test version key with more specific ones. The migration will be done automatically on upgrade of refreshVersions, without upgrading the versions of androidx.tests dependencies themselves.We also removed many obsolete dependency notations from refreshVersions. Just like for the 0.30.0 release, this should not break your build as we implemented a robust replacement mechanism that also inserts migration guidance comments. ✨
+Thanks to Brady Aiello, Mike Gray, and Kamalesh for their contributions in adding dependency notations!
+We raised the minimum supported Gradle version to 6.8, because we started to use Kotlin 1.4 features, and Gradle pins the stdlib version. Since at the time of writing, the latest Gradle version is 7.3, we believe it won’t actually block any of our users. We have a short section about updating Gradle on our website here, feel free to check it out if it can help you.
+dependencyResolutionManagement are now supported (Gradle 7+)¶Since Gradle 7, you can declare repositories of the entire Gradle project (including all subprojects and their buildscript)
+in the dependencyResolutionManagement block in the settings.gradle[.kts] file.
+Unfortunately, refreshVersions didn’t support it, so, unless you also kept repositories declared with allprojects, or per project, you would end up with all version entries in the versions.properties file marked as unused after running the refreshVersions task, and you’d not see the newer updates.
This release resolves this issue, and we are eager to use it in our projects ourselves.
+Sometimes, libraries get deprecated, or the maintainers change the maven coordinates.
+When it happens, this fact is unfortunately not included in the maven-metadata.xml files, or any other standard metadata. That means tools like refreshVersions will believe you’re on the latest versions, when you’re not, because it lacks the necessary information.
One example is Google that changed the maven coordinates of all their AndroidX Wear Watchface artifacts several weeks ago.
+It took us time to catch-up with this change because we wanted to design a generic mechanism for this recurrent problem, and provide the best experience for you, and ourselves.
+From now on, we have the ability to remove old or deprecated built-in dependency notations in refreshVersions, and doing so will not break your builds, nor will it change the dependencies of your project. However, it’ll help you notice the deprecation, and it’ll help you switch to the replacement dependencies, if any.
+The way it works is that we keep a versioned list of all the removals, and on refreshVersions upgrade, an automatic replacement will put back the hardcoded maven coordinates, using the version placeholder, and it will add our handwritten TODO/FIXME comments, along with a perfectly aligned replacement suggestion if there is any, so that moving to the newer artifact is as easy as upgrading to a newer version in the versions.properties file. We designed the system so that it cannot break your build, even if you were using withVersion(…) or other DependencyNotation extensions, even if you have code comments or special string literals.
It also supports the case where we just move a dependency notation to another place, or change its name, without changing the maven coordinates.
+Because of this change, it’s important that you check the git diff after upgrading refreshVersions and running the first Gradle reload/sync/build, so you can see if there’s been any changes, and if you might want to switch to any replacement dependencies.
+This change will enable us to keep the built-in dependency notations updated with less effort, so we’re very happy to have it ready, and fully tested.
+We’ve already started to take advantage of it to clean up all the discontinued artifacts we found in AndroidX.
+dependencyResolutionManagement block were ignored. Now, they are taken into account.refreshVersionsMigrate task wasn’t inserting new entries in alphabetical order. Now it is.refreshVersionsMigrate task wasn’t migrating buildscript dependencies. Now it is.Thanks to Emil Kantis for the kotest dependencies fixes! +Thanks to Kamalesh for the help in updating AndroidX dependency notations! +Thanks to Simon Marquis for adding Square.moshi.adapters, and helping contributors using Windows!
+Fix a bug that broke standalone buildSrc builds.
+Fix a regression that brought a KotlinNullPointerException in the build. We apologize for the issue. Thanks to Marcin and Craig for the report.
Thanks to Filip Czaplicki, who contributed to the new dependency notations!
+We now support npm dependencies for Kotlin/JS!
+Just put the version placeholder (_) in place of the version, and you’re good to go.
The version keys follow a simple naming scheme where their id is prefixed with npm, here are two examples:
+- version.npm.react=17.0.2
+- version.npm.@googlemaps/js-api-loader=1.12.2
Special thanks to NikkyAI who authored the feature, and pair-programmed with us to refine it!
+Before this release, when we added new dependency notations and shorter version keys, it could lead to an unwanted upgrade of the dependency in the project upgrading refreshVersions. With this release, we make sure to copy the same version if we add or change the version key, and it will also work if we decide to remove one. This ensures that upgrading refreshVersions will not be able to affect your application or library.
+Thanks to Brady Aiello from Touchlab for helping out via pair-programming!
+Thanks to Brady Aiello again, who contributed to these new dependency notations!
+We are now ready to accept dependency notation contributions for high-quality and popular dependencies from the Kotlin ecosystem!
+Look for issues with the Dependency notations and up-for-grabs tags to find one you can directly contribute to, or submit a new issue to ask for a new one to be added. We updated the contributing guide on the website, it now has a guide dedicated to it here.
## unused comments on top of unused entries in the versions.properties file after you run the refreshVersions task, so you know which ones are obsolete and can be removed.rejectVersionIf { … } predicate available in the refreshVersions { … } extension in your settings.gradle[.kts] file will allow you to filter any kind of versions you don’t want to know about. It can be handy to filter snapshots out for example.withVersionPlaceholder(), withVersion(…), and withoutVersion().The refreshVersionsMigrate will now use the built-in dependency notations if they match existing dependencies.
Add task refreshVersionsMigrate that adds all missing entries in versions.properties and try to migrate the build.gradle(.kts) and other known files like libraries.gradle so that the version placeholder _ is used everywhere. Please try it out and give us your feedback for refreshVersionsMigrate
_) directly in build.gradle(.kts) files, Android lint would trigger an unwanted warning, or error in the case of the Android build tools (aka. AGP, the Android Gradle Plugin). To avoid this inconvenience, running the refreshVersions task will now automatically check if it’s running on an Android project, and in such cases, will edit (safely) the lint.xml file, creating it if needed, and add the needed rules to have these specific warnings and errors ignored._) for the Google.android.material.composeThemeAdapter dependency notation.org.jetbrains.kotlinx.benchmark and any other Gradle plugin with an id starting with org.jetbrains.kotlinx because it matched over org.jetbrains.kotlin as well. We are now matching on org.jetbrains.kotlin. to avoid this issue.versionFor function that takes a dependency notation, or a version key, and returns the corresponding version that is in the versions.properties file. For example, if you use Jetpack Compose, you can leverage it to set kotlinCompilerExtensionVersion with versionFor(AndroidX.compose.ui). Groovy DSL users can find it in the Versions class.settings.gradle.kts and settings.gradle files (including refreshVersions itself).settings.gradle.kts or settings.gradle file. Note that if you want to apply it to buildSrc as well, there’s a gotcha regarding defining the version. The best thing is that on upgrade, refreshVersions will automatically replace the old & verbose bootstrap with the new plugin setup, and that works for buildSrc special case as well. We made many tests to ensure that this logic is reliable, doesn’t break any code, doesn’t remove important comments, and doesn’t affect custom configuration in any way.Testing object, and for Orchid.Square.sqlDelight.coroutinesExtensions dependency notation can lead to such an error: Failed to resolve: coroutines-extensions-1.4.4-_. If you get a similar error on upgrade, it’s because you applied a fix like that one: Square.sqlDelight.coroutinesExtensions + ":_". You now can (must) remove it.extraArtifactVersionKeyRules could not be taken into account if there was an overlapping rule already present in refreshVersions, even if it was more specific. That ordering issue has now been fixed, the most specific rule will now always be the one applied.Thanks to all the folks that joined Louis CAD in pair-programming sessions:
+
Waqas Ahmed
Benjamin Orsini
Zahra Heydari
Alexi Bre
Jean-Michel FayardThese were critical to ensure thorough testing, and great quality, all while keeping motivation to keep going.
+We’re very grateful for your time and help, and we think our users will be as well. 🙏
+Also, thanks to all the folks that reported issues. It was very helpful to prioritize on our side.
+refreshVersions task twice or more would fail with “executor rejected” as an error message, until the Gradle daemon is killed. This has now been fixed. (Issue #263)refreshVersions task was failing after the latest Gradle release candidate was superseded by the stable release because the API would return an empty JSON object after this, which we didn’t expect.refreshVersionsDependenciesMapping)AndroidX.compose.compiler dependency notation, which means it now works only for Compose 1.0.0-alpha04 and more future versions.Firebase ML Kit has been rebranded to Google ML Kit along with API and feature changes since 2020-08-14 update, so we deprecated the Firebase.mlKit dependencies and introduced new ones in Google.android.playServices.mlKit and Google.mlKit.
This is a major release that brings surface-level and internal changes, paving the way for the upcoming 1.0 release.
+The plugin setup/bootstrap has changed, so check out the updated documentation in Setup.
+settings.gradle[.kts] file if needed for easy upgrade. This allows you to get future improvements conveniently.buildscript dependencies. It now works just like regular dependencies.buildSrcversions.properties, build.gradle and build.gradle.kts files in. This version of refreshVersions integrates the facility to
+let future versions of refreshVersions that migration is needed, and from which version. This is a very important change that ensures you can keep your projects updated with the least effort possible.Testing object)Several dependencies notations have been renamed in this release (compared to version 0.9.4).
+If you were using one of the following, you’ll need to migrate these usages.
+We recommend to use “Replace in Path” in IntelliJ or Android Studio, filtering for the *.gradle.kts or *.gradle file extensions to do these replacements with ease.
Note that for future versions, refreshVersions will be able to do this automatically.
+Here’s the list of renamed dependency notations:
+AndroidX.coreKtx -> AndroidX.core.ktxAndroidX.coreRole -> AndroidX.core.roleSquare.retrofit2.adapter.retrofitJava8 -> Square.retrofit2.adapter.java8Square.retrofit2.adapter.retrofitRxJava1 -> Square.retrofit2.adapter.rxJava1Square.retrofit2.adapter.retrofitRxJava2 -> Square.retrofit2.adapter.rxJava2Testing.junit.junitJupiter -> Testing.junitTesting.mockK.mockK -> Testing.mockKrefreshVersions task cancellable during network requests.Ktor no longer uses the native suffixed artifacts (because Kotlin 1.4 drops them, as the main ones become multiplatform)AndroidX.test.ext.jankTestHelper notation and few other ones in Firebase.mlKit had wrong maven coordinates. This has been fixed, and tests have been added to prevent it from happening again on any dependency notation we provide.See Built-in Dependency Notations
+
refreshVersions provides read-to-use organized dependency notations for select +popular libraries of the following ecosystems:
+That doesn’t prevent you from using refreshVersions in a Gradle project that is not using Kotlin or is not an Android project.
+You can use them in any build.gradle or build.gradle.kts file.
Here’s an example of how it looks like in the IDE:
+No imports needed.
+
Autocomplete in IDE for easy discoverability.
+
You can see all the dependency objects in this directory.
+All these dependency notations specify their version as the version
+placeholder (_), so refreshVersions can replace them seamlessly with the corresponding
+value defined in the versions.properties file, via Gradle APIs.
+The same will work for your own, non-built-in dependencies if you use that same version placeholder.
After adding a dependency that doesn’t have its version specified in the
+versions.properties file yet, refreshVersions will edit it and put the
+most stable recent version in it on the next Gradle sync (or any other
+Gradle run).
It will also put any less stable versions as comments, allowing you to +quickly upgrade if needed.
+This section doesn’t apply to plugins that are configured in a
+buildscript block (since these have their versions configured like
+regular dependencies), but only to those that are configured solely with
+a plugin id.
To add such a plugin, do as usual, but do not specify the version in the
+build.gradle or build.gradle.kts file. Instead, set it up like so in
+the versions.properties file:
plugin.com.apollographql.apollo=2.4.1
+
+plugin.com.squareup.sqldelight=1.4.3
+Then you can omit the plugin version in all build.gradle(.kts) of your project:
plugins {
+ id("com.squareup.sqldelight")
+ id("com.apollographql.apollo")
+}
+plugins {
+ id 'com.squareup.sqldelight'
+ id 'com.apollographql.apollo'
+}
+As you see, the convention is pretty simple. The key is the id of the plugin, prefixed by plugin.: plugin.some.plugin.id sets the version of the plugin of id some.plugin.id.
In some cases, you might need to get the version defined in the versions.properties file in a Gradle script.
+For these cases, there’s the versionFor function that takes either a version key, or a full dependency notation.
Here’s a usage example with Jetpack Compose in an Android project:
+import de.fayard.refreshVersions.core.versionFor
+
+...
+
+composeOptions {
+ kotlinCompilerExtensionVersion = versionFor(AndroidX.compose.ui)
+}
+import static de.fayard.refreshVersions.core.Versions.versionFor
+
+...
+
+composeOptions {
+ kotlinCompilerExtensionVersion = versionFor(project, AndroidX.compose.ui)
+}
+Using versionFor("version.androidx.compose.ui") would also work, so long as version.androidx.compose.ui is defined in the versions.properties file.
Generally speaking, so long as you have the version placeholder (_) in place of the version,
+refreshVersions will handle it.
Below are some ways to deal with the dependency notations that are not built-in.
+The Gradle task buildSrcLibs can be used to automatically generate a Libs.kt file in the buildSrc, that will contain all the dependency notations curently used in your build.
To use it, you need to enable it:
+plugins {
+ // See https://jmfayard.github.io/refreshVersions
+ id("de.fayard.refreshVersions") version "0.60.4"
+}
+
+refreshVersions {
+ enableBuildSrcLibs() // <-- Add this
+}
+plugins {
+ // See https://jmfayard.github.io/refreshVersions
+ id 'de.fayard.refreshVersions' version '0.60.4'
+}
+
+refreshVersions {
+ enableBuildSrcLibs() // <-- Add this
+}
+Then you can use the command ./gradlew buildSrcLibs to generate accessors for your dependencies
$ ./gradlew buildSrcLibs
+> Task :buildSrcLibs
+ new file: buildSrc/build.gradle.kts
+ new file: buildSrc/src/main/kotlin/Libs.kt
+The generated file will look like this:
+/**
+ * Generated by `$ ./gradlew buildSrcLibs`
+ */
+object Libs {
+
+ const val guava: String = "com.google.guava:guava:_"
+
+ const val guice: String = "com.google.inject:guice:_"
+
+}
+Because this file uses the version placeholder (_), it is compatible with refreshVersions!
Read more: gradle buildSrcVersions.
+JetBrains offers the plugin Package Search, +it is compatible with both IntelliJ IDEA and Android Studio. It also has a website
+Package Search provides a nice UX to add a dependency:
+
Can you use it with refreshVersions?
+Sure, just use the version placeholder (_).
Gradle 7+ comes with its own feature for centralizing dependencies: Versions Catalogs.
+With Versions Catalog, you have a file like gradle/libs.versions.toml where you can centralize all your dependencies and benefit from typesafe accessors in your build.gradle[.kts] file.
We support updating this version catalog. If you want to keep versions in the versions.properties file, you can use the version placeholder (_).
An older approach to centralize dependencies is to have a libraries.gradle file:
ext.libraries = [ // Groovy map literal
+ spring_core: "org.springframework:spring-core:3.1",
+ junit: "junit:junit:4.10"
+]
+apply(from = "../libraries.gradle")
+
+dependencies {
+ compile libraries.spring_core
+ testCompile libraries.junit
+}
+Does that work with refreshVersions too? Yes, just use the version placeholder (_):
ext.libraries = [ // Groovy map literal
+- spring_core: "org.springframework:spring-core:3.1",
++ spring_core: "org.springframework:spring-core:_",
+- junit: "junit:junit:4.10"
++ junit: "junit:junit:_"
+]
+