Permissive third party alias list for refreshVersions
I'm writing this issue to let developers know that I created a side project for refreshVersions, hosting additional aliases: refreshversions-aliases.
Combined use is trivial:
import de.fayard.dependencies.bootstrapRefreshVersionsAndDependencies
import org.danilopianini.VersionAliases.justAdditionalAliases
buildscript {
repositories {
gradlePluginPortal()
mavenCentral()
}
dependencies {
classpath("de.fayard:dependencies:+")
classpath("org.danilopianini:refreshversions-aliases:+")
}
}
bootstrapRefreshVersionsAndDependencies(justAdditionalAliases)
The policy for alias acceptance will be less stringent than the one refreshVersions, the root reason for the existence of this project is to simplify / lighten the version upgrades, especially when performed via UpGradle. Hence, one requirement is that every alias groups together (potentially) multiple dependencies, it's meant to be a grouping / synchronization tool rather than a renaming tool.
If the devs of refreshVersions deem it appropriate, I'd ask them to mention in the README.md both UpGradle and refreshversions-aliases as automation related tools for projects using refreshVersions.
Cheers
You should not use version ranges + because it makes builds not really reproducible, and can break future builds.
FYI, de.fayard:dependencies will be deprecated (with a replacement). The API is not stable until we reach 1.0 (where only a 2.0 should break it starting from that point).
About promoting other plugins, this is not something we can do now as the API is unstable, and involving third party dependencies can make future upgrades more complicated.
I'll review that again when 1.0 is there.
Please, be patient, we should get there this year :)
BTW, you can peek at the priority list here to see what's coming next.
No problem @LouisCAD, I opened this issue to let you know. No hurry.
I'm well aware of the issues related to +, but until #177 is worked out I prefer to compromise the build reproducibility over performing further manual routing maintenance.
FYI @DanySK , since refreshVersions 0.9.5, running the refreshVersions task will also look for updates for refreshVersions itself, and will add available updates comments and migration preparation automatically in the settings.gradle[.kts] file, and for buildSrc too, so you should not need to use the unsafe +.
Nice! Once the next version is available and I can target the upgrade to run some tests, I'll prepare a module for upgradle or update the existing one, and drop the dangerous + in favor of automatic controlled updates.