<@UGCM6H67J> I too feel your pain. Library incompa...

# multiplatform

[spierce7]

@Kris Wong I too feel your pain. Library incompatibility between versions is proving to be far more painful than I expected.

[Kris Wong]

very much so

[Kris Wong]

it's unsustainable

[Kris Wong]

there's no way this sees widespread adoption with this shortcoming

[spierce7]

Scala has this same problem. Major releases are not binary compatible. It super fragments their system, and has caused lots of problems for the server teams at my company, which is a scala shop.

[Kris Wong]

i could even buy that major releases are not binary compatible. but minor releases... no way

[spierce7]

it’s early stages right now. It’ll get more compatible over time.

[Kris Wong]

🤞

[kpgalligan]

This version was a bad special case, because of mt coroutines. Not saying it isn’t painful, but in the normal case it would’ve been a few days after 1.3.70 released

[Kris Wong]

it will become more of a problem as more libraries begin to become unmaintained. right now it's all still very new.

[Arkadii Ivanov]

@kpgalligan How mt coroutines can affect libraries upgrades to Kotlin 1.3.70?

[Kris Wong]

they did not release a version that supported 1.3.7x until 1.3.71

[Arkadii Ivanov]

But how a library might be affected by this? mt coroutines are not merged yet, there is a separate branch and separate artifacts provided for every Kotlin version. Libraries should not use mt coroutines.

[Arkadii Ivanov]

It's ok to play with an unreleased stuff on your own risk, but big libraries should not do this.

[spierce7]

All my companies internal mpp libs are all using mt coroutines. The libs would be useless if they didn’t.

[Arkadii Ivanov]

This is your explicit decision

[spierce7]

It’s ok to play with an unreleased stuff on your own risk

I kind of feel like this is Kotlin/native in general right now 😛

[Arkadii Ivanov]

E.g. we have a policy to not use any alphas, betas or any other unstable things. E.g. we are not using inline classes.

[audriusk]

we need to be grateful that there are such companies which goes first in uncharted territories 😄

[Arkadii Ivanov]

Yeah I agree! But a stable version of a public library should not use unstable things.

[Kris Wong]

philosophical debates aside, that's the reason

[Arkadii Ivanov]

Or provide separate builds with this versions

[Kris Wong]

you may not agree, but that's what it is

[Arkadii Ivanov]

That's sad 😞

[Arkadii Ivanov]

Will stay with 1.3.60

[kpgalligan]

SQLDelight uses it internally

[kpgalligan]

We figured it would come out sooner, but then I think we all kind of got distracted

[kpgalligan]

I just spent an hour decontaminating a food delivery. NYC!

[kpgalligan]

“it will become more of a problem as more libraries begin to become unmaintained. right now it’s all still very new.” Sure. Open source is one issue. If you really need it, you can deal. The abandoned library problem was similar for Swift, etc. Java folks haven’t had to deal with it as much. To describe the situation as “unsustainable” seems a bit much, though. Frustrating, sure, but not unsustainable

[kpgalligan]

IMHO

[russhwolf]

Yeah I see it more as, this is why it's still called "beta". Not everything is ideal right now because it's still a work-in-progress, but you should expect that sort of issue as an early adopter.

[russhwolf]

One of the things I'm learning to be more comfortable with to help deal with this (and a great benefit of the fact that this ecosystem is almost entirely open-source) is compiling external dependencies yourself against newer versions, when necessary.

[Arkadii Ivanov]

@kpgalligan

SQLDelight uses it internally

But why?

[kpgalligan]

Flow

[kpgalligan]

coroutines-extensions

[Arkadii Ivanov]

What if I'm also using Flow and coroutines but only stable release. How it will work?

[spierce7]

I’m not sure how Gradle deals with non numeric versions (like this case), but it’s my understanding that it would use the higher version number.

[kpgalligan]

I didn’t actually add it myself, so I won’t get super into that debate. However, for the projects we’re working on, we use mt coroutines and force that to be the version used. For example, in KaMP Kit, we need to suppress the version ktor wants to use: https://github.com/touchlab/KaMPKit/blob/master/shared/build.gradle.kts#L80

[kpgalligan]

We copy/pasted coroutines extensions from sqldelight into KaMP Kit to avoid the issue when we were building it: https://github.com/touchlab/KaMPKit/blob/master/shared/src/commonMain/kotlin/co/touchlab/kampstarter/sqldelight/CoroutinesExtensions.kt

[Arkadii Ivanov]

So the library may force mt coroutines for my project. Not for me. Thanks for the explanation. Do you remember since what Kotlin version mt coroutines were introduced in SQL delight?

I completely understand people trying the new fancy things. They want to be up to date. But for some companies this is not an option. And this situation is really disappointing, since I'm just lucky that I read this topic and asked the question. Any unstable/unreleased stuff must be opt-in, not opt-out.

[Kris Wong]

i mean, technically KMP in general is not officially released

[kpgalligan]

“I didn’t actually add it myself”, as mentioned, so I don’t know what version. It only applies to the coroutines extensions, and only native, if that helps.

[Gunslingor]

Yeah, like I have no idea if this is compatible with multiplatform... think its a fundamental issue, need library stands like css if its turning out to be like that, at least for me.

https://github.com/craigburke/karma-gradle