I’ve been reading about providing multiple variants of a Gradle plugin based on the Gradle version https://docs.gradle.org/current/userguide/implementing_gradle_plugins.html#plugin-with-variants So I can publish a plugin for Gradle 7, and a variant of the same plugin for Gradle 6 - both have the same plugin ID, and Gradle will select the appropriate one dynamically, based on the receiver’s Gradle version. Instead, could I publish a Gradle plugin that has variants for Kotlin 1.8, 1.7, and 1.6? So if my plugin is applied when the Kotlin 1.7 plugin is present, Gradle will select my plugin variant that’s compatible with 1.7. The reason being is that I’m getting ClassNotFound errors with KotlinBasePlugin and KotlinProjectExtension.

Not automatically selectable I think. When Gradle resolves the plugin artifact it knows its own version. But it neither knows which Kotlin plugin will be applied or will be on the class path or whether any Kotlin plugin will be applied at all actually. If you want to support these Kotlin Gradle plugins and not define a minimum version for example by depending on it, I guess the best solution from a user perspective is the usual checking what is available and taking different code paths. So you can have a class for 1.6, a class for 1.7, and a class for 1.8 and then in the main plugin class you check for something, for example whether

KotlinProjectExtension

is available and then use the compatible class, something like that.