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

very much so

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.

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

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

🤞

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

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

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

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

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.

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

This is your explicit decision

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 😛

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.

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

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

philosophical debates aside, that's the reason

Or provide separate builds with this versions

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

That's sad 😞

SQLDelight uses it internally

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.

@kpgalligan

SQLDelight uses it internally

But why?

Flow

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

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.

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

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.

i mean, technically KMP in general is not officially released

“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.

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