Double versioning scheme for `runtime` modules is rather cumbersome for external integrations

[whyoleg]

As runtime is published with version like 1.9.24-0.1.0 (or generally KOTLIN_VERSION-LIBRARY_VERSION), I'm a bit frustrated on what is the best way to depend on it in external integration. Use-case: I do want to implement kotlinx-rpc over rsocket-kotlin. That means, that I need to depend on some version of the kotlinx-rpc-runtime module. On current moment rsocket-kotlin is published with Kotlin=2.0.0. There is no version of kotlinx-rpc for Kotlin 2.0.0. That's fine, looks like I can use just 1.9.24-0.1.0. This means, that I will fix anyway fix version of Kotlin at runtime for consumers anyway (compileOnly dependencies are not supported in KMP, only for JVM). Or I can try to lower Kotlin version of other modules, but not sure if it's possible, because I need kotlinx.coroutines and kotlinx.io, which will be built with Kotlin 2.0 soon. And this is not only related to rsocket-kotlin but to any other dependency which will try to expose kotlinx-rpc somehow.

So the question is - does it really make sense to use 1.9.24-0.1.0 version for runtime? What is the use-case for this. I understand why it's needed for compiler plugin, but for runtime it feels both unnatural and not friendly for external integrations. There is no problems of course for out-of-the-box modules.

[Mr3zee]

Let's have a discussion on it, I'm not sure what's the best scenario right now