Unexpected new dependency in 2.44.1

[TWiStErRob]

Hi, this is more of an FYI, not sure exactly what could go wrong...

During the recent release I noticed that the kapt classpath has an inconsistent Kotlin version + a new kotlinpoet dependency.

See the diffs here (click Raw output in Lockfile diffs): https://github.com/TWiStErRob/net.twisterrob.cinema/pull/277/checks?check_run_id=9441062559

The inconsistency is with kotlin-reflect: dagger-compiler depends on stdlib 1.7, but the new kotlinpoet brings in reflect 1.6.10.

I think it's unexpected purely because of how the release notes is described (sounds like simple bugfix, but there seem to be significant changes related to ksp in the code. cc @bcorso

[bcorso]

Hi @TWiStErRob,

We typically don't mention new dependencies in the release notes unless it's expected to cause issues. If you're seeing a particular issue let us know. However, I would expect the build system (e.g. Gradle) to handle these inconsistencies automatically, as you can't expect all of your versions from all of your libraries to be on the same exact version of all their dependencies.

I think it's unexpected purely because of how the release notes is described (sounds like simple bugfix, but there seem to be significant changes related to ksp in the code.

W.r.t. release notes, KSP support has not been released so you will not see bug fixes and features added to the release notes yet (again, we don't expect these changes to cause issues for current users, but if we do we'll mention it).

However, updates on KSP support can be found here: #2349 (FWIW, I plan to add a new update on that thread today or early next week).

[TWiStErRob]

Now we know how dependencies can break stuff 🎯 #3633
Nice quick fix!

[bcorso]

@TWiStErRob just to clarify, I still believe the build system should handle inconsistencies between various versions of dependencies (i.e. actual dependencies declared in the POM file of an artifact).

The issue in #3633 is a bit different because it wasn't supposed to be an actual dependency. In particular, we shade/repackage all of the classes in room-compiler-processing and bundle them into Dagger's artifact, so it doesn't show up as a dependency in the POM file, and the classes shouldn't ever conflict with user's room-compiler-processing since the classes are shaded. The issue in this case was that a new package was recently added to room-compiler-processing that wasn't covered by our shading rules so those classes didn't get shaded (I've added some validation to our release process to make sure this particular issue doesn't happen again in the future). Anyway, just wanted to clarify any confusion -- hope this helps.