dlew / joda-time-android

Joda-Time library with Android specialization

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Consider downgrading dependencies so that `minCompileSdk` is `30` instead of `31`

erikhuizinga opened this issue · comments

This line transitively sets the minCompileSdk to 31 for all users of this library.

implementation "androidx.startup:startup-runtime:1.1.0"

This breaks the build for projects that still have the compileSdk set to 30 or lower. An example failure build log:

> A failure occurred while executing com.android.build.gradle.internal.tasks.CheckAarMetadataWorkAction
   > One or more issues found when checking AAR metadata values:
     
     The minCompileSdk (30) specified in a
     dependency's AAR metadata (META-INF/com/android/build/gradle/aar-metadata.properties)
     is greater than this module's compileSdkVersion (android-29).
     Dependency: androidx.startup:startup-runtime:1.1.0.
     AAR metadata file: ...

In this example, the project doesn't depend directly on androidx.startup:startup-runtime:1.1.0, but it does on net.danlew:android.joda:2.10.12.2 which depends on the former. The minCompileSdk leaks from that dep into the client's project.

Because Google Play requires targetSdk 30, it might not be uncommon that compileSdk still is 30 in various Android projects, including consumers of joda-time-android.

If this change is acceptable or intentional, then this issue can be closed. Otherwise, consider downgrading the dependency version (and checking if other dependencies are also transitively imposing minCompileSdk greater than 30).

I could be convinced to lower compileSdkVersion but I'm skeptical. Typically you should always be compiling to the latest SDK version - what's blocking you from upgrading?

(Keep in mind, targetSdk is a different beast; you can compile to a higher SDK than you target.)

I agree, but it's not the point. The point is that a library that seems to not depend on the compile SDK suddenly imposes a compile SDK version bump. That decreases the developer experience of this library for everybody that hasn't eagerly kept the compile SDK version up to date. It's a side effect, seemingly.

Note that this is a 'problem' in general: any lib implementing (or api-ing?) an AndroidX lib that requires compile SDK 31 will have its users' builds break... I guess that this issue is on AndroidX, because they chose to add this requirement recently for many (if not all) of their libs. And it's undocumented, AFAIK.

The fix on the user end should be trivial, so probably not worth fixing by you. Besides, if you'd stick with compatibility for the previous compile SDK version, then your lib will likely not be able to upgrade AndroidX dependencies for a year, always lagging behind the latest and greatest possibilities (in theory).

Makes you wonder what the use is of the compile SDK version, if AndroidX forces you to use the latest stable by default... 🤔

Feel free to close this issue.

I'm not really sure I understand the exact ask here - is it that joda-time-android stops depending on androidx.startup?

Concretely, I ask to stop depending on libraries that set minCompileSdk to greater than 30. E.g. if you'd downgrade AndroidX Startup, the previous version likely doesn't require that.

But I now remember the support library, which I think always has had the implicit requirement that your compile SDK version is at least the support lib's major version. Since AndroidX, that major version isn't in the version names any more, so I guess that's partially where the issue lies (like I wrote before): AndroidX fails to communicate / document the minimum required compile SDK:

And actually the minimum compile SDK is 31. This, while the Play Store accepts apps (or app updates) with target SDK 30 and therefore it is safe to assume that some of those apps will also use compile SDK 30. That leads to the problem described in this issue: breaking builds. However, like discussed it's not a problem to upgrade the compile SDK version, so I'm closing this.