Something that I've never thought about until rece...

# coroutines

[Leon Linhart]

Something that I've never thought about until recently: Is the versioning scheme used for kotlinx libraries documented?
What's got me curious it that at least coroutines increases the required Kotlin API version in "minor" releases which is technically a breaking change, so it's not SemVer-compatible. 🤔

[jw]

Even bug fixes are technically breaking changes though because they can be load-bearing.

[jw]

I find it easiest to think about semver in terms of the binary API surface the library provides

[jw]

Can you compile your code against version N and use version M at runtime? If that is not true, then it's a binary breaking change.

[jw]

Upgrading the transitive stdlib to 2.0 from 1.9.21 in a minor version is also fine. Your code would still run fine since the stdlib guarantees forward compatibility.

[jw]

Imposing a new version of the compiler (which kotlinx.serialization has done) or deprecating things as error/hidden which is source-breaking doesn't seem like it warrants any consideration in semver, although I would probably still do a minor bump here just for visibilities sake

[Leon Linhart]

I'm tripping a bit about the transitivity aspect in general. Part of what prompted me to ask is that I noticed that tests for a Gradle plugin were failing for a PR to upgrade kotlinx libraries. For example, on older versions of Gradle, kotlin/enums/EnumEntriesKt does not resolve. The transitive dependency is not pulled because it is effectively constrained by the runtime.

This got me thinking whether this is a compatibility issue in general or just very specific to this constrained setup, and I tend to believe that it might actually be the former.

[Leon Linhart]

On second read, I might have confused myself thinking too much about that though.