This message was deleted.

I'm also curious about this: compatibility of what, exactly?

Kotlin at all

i know that gradle ships a different version of the stdlib depending on the version, and that the kotlin dsl is written targeting a different kotlin version depending on the gradle version. but i think if you target the same kotlin version that the minimum gradle you want to support ships with, you should generally be OK

Is it like Scala, where the ABI changes from language version to language version?

Gradle provides a runtime in which plugins run. This runtime contains a hard-coded version of Groovy and Kotlin that comes higher in the class loader hierarchy so is used. Your plugin and all transitive dependencies you use have to be compatible with the runtime provided by that Gradle version it is currently used in.

re: like scala, no kotlin is not like that

So how is it different from Java, where you're generally fine as long as you target an old enough JDK?

i think its the same, as long as you target an old enough kotlin version.

Kotlin metadata has some forward compatibility limitations

for example, i target 1.4.20 in my plugins, and kotlin dsl 1.4.9 since i target gradle 5+

Except that Kotlin is faster moving, also in terms of deprecation and removal. Something that works in Java 8 most likely runs fine with Java 18. With Kotlin this is not the case afair.

gradle will throw warnings if you pull in a version of kotlin that is newer than the version the kotlin DSL is targeting. they are annoying, but i have not seen any issues from that yet. i just downgrade tot he kotlin version the DSL wants to make the warnings go away

Then you still have the problem, that Gradle 7.5 suddenly includes Kotlin 1.6.10 instead of 1.5.x and your plugin might become incompatible because of that. And such updates happen in minor Gradle versions.

The backward compatibility of

kotlin-stdlib

is pretty good. I don't think the n-2 rule applies there? Or at least I haven't heard a case where that was an issue

Well the point is that it can break even in a minor Gradle version change. And you just have less problems and concerns if you write the plugins in Java. Of course this is just a personal opinion and everyone can do whatever he likes. :-)

i have also seen (like @Martin) that kotlin backwards compatibility since 1.x has been very good, and they do a good job with their deprecation lifecycle and compiler warnings. I think it is totally something to be aware of though, and something to keep in mind, especially if you are targeting many major versions of gradle. thanks for the discussion.

Always a pleasure 🙂

I don't think the n-2 rule applies there

Yup, the "2 backward, 1 forward" rule is for the binary format: https://kotlinlang.org/docs/kotlin-evolution.html#evolving-the-binary-format

I love you, Java. Never change

Ah, so that only affects the compiler @Martin?

Yep

Hm, but on the linked page it says it can always read all older versions, not only 2 backwards

Right 🤔

Anyway, for this discussion it seems to be irrelevant. But even in the stdlib there are incompatible changes. I've seen methods that were deprecated, then removed and then even readded with a different signature. Which still makes me feel like Kotlin is too dynamic for a reliable, as compatible as possible, public plugin.

Stdlib is case by case. I'm scrolling to find binary breaking changes in https://kotlinlang.org/docs/compatibility-guide-15.html#forbid-spread-operator-in-signature-polymorphic-calls but there aren't many

The method I talk about was stdlib afair. But I cannot say now which it was.

yeah, my use case is internal plugins where we are only committed to supporting 2 major gradle versions at a time, so in that use case, I think the compatibility is not an issue. but a public plugin that is supporting many more gradle versions is a different assessment

And another thing that makes me uneasy are those warnings about different versions of Kotlin libraries in the class path

Searching the binary incompatible changes since 1.3, I found only one and I think it only applies to JS: https://kotlinlang.org/docs/compatibility-guide-16.html#hide-implementation-and-interop-specific-fun[…]s-from-the-public-api-of-classes-in-kotlin-js

Well, seems not all changes were doumented then, another point to be uneasy :-)

We need proof 😉

Maybe if I remember, as I said, I don't remember which methods it was about right now.

🙂

kotlin-stdlib changes like the min/notNull change are binary compatible, source-incompatible. changes like kotlin.time.Duration representation are binary-incompatible, but also marked experimental

Ah yeah, what I had in mind was something with minByOrNull or something like that.

there are no issues with binary incompatibility there, and the source transition was gradual over like 4 or 5 releases iirc