A modern programming language that makes developers happier.

kotlinlang

I am writin a lib: <https://github.com/jasync-sql/jasync-sql> and just started to use coroutines internal (not in exposed api). Since this is new I am not using experimental packages. I wonder how this affects lib users? They will not be able to use it if they are using experimental coroutines?

I asked in forum but didn't get an answer

If you use release coroutines your user cannot compile with your library using 1.2 compiler

If you use experimental ones, that it can used from 1.2 and 1.3

ok, from that sentence I thought experimental will not be available in 1.3: `Note, that release of kotlinx.coroutines will drop all the deprecated declarations from experimental 0.x releases`

it appears here: <https://blog.jetbrains.com/kotlin/2018/09/kotlin-1-3-rc-is-here-migrate-your-coroutines/>

so since the usage of coroutines is optional in my lib at the moment, I thought to use provide scope so that people will have to provide new coroutines to use it.

Isn't it makes sense to release an 0.x version with the non-experimental packages, then I can enfore a version higher than that?

kotlinx.coroutines library of course not compatible. but stdlib part is backward compatible

So if you use kotlinx.coroutines you cannot support old and new

Yes, I am using `kotlinx.coroutines`, so what's my best option? the optional dependency I described above with the new version? to save me from migrating later?

~kotlinx.coroutines for 1.2 and 1.3 are binary incompatible~

Actually just understand that you can use it

not sure why do you need optional dependency

Kotlinx coroutines for 1.3 use another package

Version for 1.3 cannot be used by 1.2 consumer

and do you think version for 1.2 can be used by 1.3 consumer?

But consumer will have 2 version of kotlinx.coroutines in classpath

can you just support 2 branches witn new and old coroutines?

Anyway,  if you do not expose experimental coroutines as API it should be transparent for consumer

`But consumer will have 2 version of kotlinx.coroutines in classpath`  - I don't think that is possible if kotlinx.coroutines have the same artifact id + group id

<@U2E974ELT> am I missing something here? are there any other alternatives for library developers?

In my library I just have 2 branches one for 1.2 and one for 1.3

That is the way to go! With Kotlin 1.3 release around the corner it will be over soon.

I wonder which corner this is around. if it will be released in October then I will wait and keep myself safe from having to maintain branches