Gradle-play-publisher: Incompatible with Gradle 6.2-rc-1

[ZacSweers]

Describe the bug

When updating to Gradle 6.2-rc-1, this log API no longer exists.

Caused by: java.lang.NoSuchMethodError: org.gradle.util.DeprecationLogger.nagUserWith(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)V
        at com.github.triplet.gradle.play.internal.ValidationKt.validateCreds(Validation.kt:27)
        at com.github.triplet.gradle.play.PlayPublisherPlugin$applyInternal$1.execute(PlayPublisherPlugin.kt:141)
        at com.github.triplet.gradle.play.PlayPublisherPlugin$applyInternal$1.execute(PlayPublisherPlugin.kt:49)

How To Reproduce

https://github.com/ZacSweers/CatchUp/tree/z/gradle62rc1

Attempt to run any gradle command, such as ./gradlew :app:assembleDebug

Versions

• Gradle Play Publisher: 2.6.2
• Gradle Wrapper: 6.2-rc-1
• Android Gradle Plugin: 4.0.0-alpha09

Tasks executed

N/A fails at configuration

Expected behavior

Crash should not happen

Additional context (if a crash, provide stack trace)

See above

[SUPERCILEX]

FYI, I've decided to wait until 6.2 reaches stable and require it as a minimum to keep things simple. Also hoping to do the same with AGP 3.6.0.

[pawegio]

2.7.1 is still incompatible with gradle 6.2

I'm getting following exception:

java.lang.NoClassDefFoundError: com/android/Version at
com.github.triplet.gradle.common.validation.ValidationKt.validateRuntime(Validation.kt:17) at 
com.github.triplet.gradle.play.PlayPublisherPlugin.apply(PlayPublisherPlugin.kt:54) at 
com.github.triplet.gradle.play.PlayPublisherPlugin.apply(PlayPublisherPlugin.kt:52)

[SUPERCILEX]

@pawegio that's unrelated, you need to be using the Android Gradle Plugin 3.6.0 or higher (a stable version hasn't shipped yet). I need to figure out a better way to report AGP classpath issues though.

[mikehardy]

With respect, as I use and love this project, this is a major semver violation - I catch things like this with CI breaks on a dependabot system so it's not so much a catch-me-unaware surprise in my project, but people attempting to upgrade to what semver implies is a "backwards-compatible feature release" will be hit with the need to upgrade apparently to gradle 6.2 and a new gradle plugin, but there are no release notes I could find or changelog indicating as such. Either a documentation update clearly flagging new minimum requirements or a semver policy that would have bumped this to 3.x (or best: a combo) would help your users and probably avoid a wave of issues that I fear (as a fellow open source maintainer) are about to head your way and waste your time :-)

[ZacSweers]

Semver allows for raising minimum versions of dependencies and doesn’t promise backward compatibility with old versions of external libraries, only binary compatibility for its own code. 2.7.0 and 2.7.1 releases on GitHub documented this raised minimum pretty clearly.

[mikehardy]

Ah strange - I swear I looked and just didn't see any docs. I suppose I look for CHANGELOG.md or a breaking changes section and should have scanned the actual releases as well.
In common usage in the react-native ecosystem semver majors are used when minimum dependencies are lifted so perhaps I come in with a different context. For us if a build used to work with previous version and with a new version where only one thing (your software) changes and the build breaks, that's breaking change, regardless of why so we bump major.

[SUPERCILEX]

@mikehardy Thanks for the feedback! I definitely have been lenient with semver at times, so I think it might be helpful if I explained my philosophy around this stuff. You might disagree with me, but at least you'll know where I'm coming from.

For starters, I'm following the example set by Google's Android Gradle Plugin team. On each release, they almost always bump the minimum required Gradle version. Xav's team does this for a few reasons, notably that it forces the ecosystem forward, allowing them to take advantage of the latest performance enabling Gradle APIs. It also helps their team ship faster since they don't have to build wrappers around old Gradle APIs to maintain compatibility. As an aside, I personally don't like the fact that Kotlin supports older Gradle versions. It's the reason they've been disappointing slow at using the new Gradle APIs. From my perspective regarding GPP, I don't have the time to maintain compatibility, nor do I want to since this is supposed to be a fun side-project to learn about the Gradle ecosystem. Furthermore, nobody is forcing you to upgrade.

Being able to stay on an older version of GPP brings me to my second point. Semantic Versioning is incredibly important in the world of libraries to circumvent dependency hell. If I depend on library A and library B which both need different versions of library C, I expect them to work together. If a binary incompatible change were to be made, either A or B would fail at runtime with some sort of class linking error. In the GPP world, we don't have to worry about any of this. Officially, there's no public API for another library to build on top of and I'm not aware of anyone trying to do so. I might be wrong, but I don't believe that strictly following semver is all that important for GPP as long as the changes are clearly stated. Obviously, if I break something major like when we'll move to Property<T> for extension configuration, I'll rev major to 3.0.

In brief, I want to stay engaged with this project by learning about the latest and greatest in the Gradle ecosystem. If that means making a change that doesn't affect your build file's code related to GPP, then I'm unlikely to rev major. Hope this clarifies things! 😸