how are people generally handling versioning with their Gradle plugins? is anyone doing strict semver where any breaking change to the public API (including but not limited to the plugin's tasks) triggers a major version bump? I'm finding myself hesitant to do a major version bump for each such change because most people don't actually use the plugin programmatically and when they see a major new release they're hesitant to adopt it and I end up doing all kinds of comms around how it's safe and won't be difficult etc

I think it makes sense. This is what KGP has been doing for a while. Is the KGP API stable these days? Feels like it's changing a lot less often

Personally, I do not see much problem with bumping a major version every time for an API breaking change, but Tony has a point about non-API consumers and adoption. If major plugins are using your APIs in the downstream, it might be better to cut a major version, though. If not, maybe one could mark API as Incubating so that there is no strong commitment to maintain compatibility there - https://docs.gradle.org/current/javadoc/org/gradle/api/Incubating.html. Then you can still do Semver without doing it 🙂

I'm trying to "hide" things with package visibility these days, because Gradle doesn't really care that classes are public or not. This only leaves the actual API / DSL (extension and task types) public, and every breaking change there means a major bump.

thanks everyone for the feedback! along these lines, what are you all doing for breaking ABI tracking? is there a good example I could borrow? I've been meaning to do that for ages but there's always a higher priority

BCV?

Metalava can help track it too

We need a BCV vs Metalava showdown 🙂

https://github.com/firebase/firebase-android-sdk/blob/2bfc0a5de4c3d384238b25f9b71ef36104a72fa0/plugins/src/main/java/com/google/firebase/gradle/plugins/Metalava.kt#L4 Simple usage

We were using Metalava initially and then switched to BCV because it was first party but sounds like Metalava can do everything BCV does and even more these days

AGP is using metalava to track their source and binary compat

looking at the BCV link from above, I see this:

The development of a separate binary compatibility validator Gradle plugin has been discontinued, and all its functionality will be moved to Kotlin Gradle Plugin starting from the 2.2.0 release.

that's slightly annoying, but maybe it doesn't matter in practice. I'll take a look at metalava! thanks

metalava is a Java CLI tool

@Aurimas Liutikas any thoughts about the metalava gradle plugin? https://github.com/tylerbwong/metalava-gradle

I haven't used it, so I don't have much to share. CLI is quote quite simple through so custom tasks are generally small

omfg, metalava is so bloated. I don't use the

google()

repo for my build-logic, so I added it just for this dep, and this is what I ended up with in order to fully resolve it and all its dependencies

exclusiveContent {
  forRepository {
    maven(url = "<https://dl.google.com/dl/android/maven2/>")
  }
  filter {
    includeGroup("com.android.tools.metalava")
    includeGroup("com.android.tools")
    includeGroup("com.android.tools.layoutlib")
    includeGroup("com.android.tools.ddms")
    includeGroup("com.android.tools.build")
    includeGroup("com.android.tools.analytics-library")
    includeGroup("com.android.tools.lint")
    includeGroup("com.android.tools.external.com-intellij")
    includeGroup("com.android.tools.external.org-jetbrains")
  }
}

we build on top of android lint

I had to download 198 MiB worth of jars to resolve this

most of it is intellij

I'm not trying to be a jerk. I'm just pointing out that this is a very large dependency

this is pretty much headless intelij

it's bizarre seeing android's layoutlib show up for this use case. Feels like some restructuring of the modules in question might be useful

why is your CI fetching sources

that's not CI, it's a local IDE sync

got it

haha

metalava itself is fairly light on depenencies outside of lint

seems like it ought to be, which is why I was surprised

Aurimas, I'm iterating on the metalava stuff and got this error. Any idea why?

> Task :metalava
Exception in thread "main" java.lang.IllegalStateException: Invalid type in API surface: PsiType:<ErrorType> for element TYPE_REFERENCE in file /User
s/trobalik/Development/dependency-analysis-gradle-plugin/src/main/kotlin/com/autonomousapps/internal/utils/moshi.kt:106
        at com.android.tools.metalava.model.psi.PsiTypeItemFactory.createTypeItem(PsiTypeItemFactory.kt:318)

Here's the code in question:

// the function definition is line 106 from the stacktrace
inline fun <reified K, reified V> File.bufferWriteJsonMap(
  set: Map<K, V>,
  withNulls: Boolean = false,
  indent: String = noJsonIndent
) {
  JsonWriter.of(sink().buffer()).use { writer ->
    getJsonMapAdapter<K, V>(withNulls).indent(indent).toJson(writer, set)
  }
}

I'm using this as a guide