undermark5
06/14/2024, 8:54 PMkotlinx-coroutines-play-services
is still using a ~6 year out of date version of com.google.android.gms:play-services-tasks
? Shouldn't that be updated?Alex Vanyo
06/14/2024, 9:41 PMkotlinx.coroutines
in this case) depends on another library B (play-services-tasks
), and library A doesn’t need anything from newer version of library B, it can be safest for library A to just keep depending on an older version and defer to the consumer of both library A and library B to keep versions more up to date than that if they want to.
If kotlinx.coroutines
updated to require the newest version of play-services-tasks
, that would transitively require the newest version of play-services-tasks
to be used by everyone downstream.
That can cause cascading dependency issues for potentially no real benefit:
If an additional library C doesn’t work with the newest version of play-services-tasks
yet for some reason, and kotlinx.coroutines
requires that version transitively, now using both library C and the latest version of kotlinx.coroutines
together won’t work.Alex Vanyo
06/14/2024, 9:43 PMplay-services-tasks
, then you can always specify that directly.undermark5
06/14/2024, 9:49 PMplay-services-tasks
library to a version that doesn't reference the legacy support library? That's why I looked into this (because that 6 year old version of play-services-tasks
has references to legacy support library). Granted, looks like the entirety of the interesting implementation of kotlinx-coroutines-play-services
is contained in a single file that would be easy enough for us to easily bring into our project on it's own.
Also, FYI there is a CVE that impacts that version of the library via transitive dependency.undermark5
06/14/2024, 9:54 PMapi("com.google.android.gms:play-services-tasks:$tasksVersion") {
exclude(group="com.android.support")
}
Alex Vanyo
06/14/2024, 10:01 PMplay-services-tasks