https://kotlinlang.org logo
Title
o

oshai

10/18/2018, 5:35 AM
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
And this holds me from merging it
g

gildor

10/18/2018, 6:30 AM
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
o

oshai

10/18/2018, 7:03 AM
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
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?
g

gildor

10/18/2018, 7:15 AM
This sentece about kotlinX.coroutines
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
o

oshai

10/18/2018, 7:21 AM
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?
g

gildor

10/18/2018, 7:21 AM
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
so probably will work
o

oshai

10/18/2018, 7:24 AM
to use it with experimental package?
g

gildor

10/18/2018, 7:25 AM
yes
version for 1.2
Version for 1.3 cannot be used by 1.2 consumer
o

oshai

10/18/2018, 7:28 AM
and do you think version for 1.2 can be used by 1.3 consumer?
g

gildor

10/18/2018, 7:30 AM
Yes, it should be possilbe, you can easily check it, just create a new 1.3 project and use kotlinx.coroutines eap13 version
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
o

oshai

10/18/2018, 8:09 AM
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
g

gildor

10/18/2018, 9:41 AM
hah %)
yeah, you right
o

oshai

10/18/2018, 9:58 AM
@elizarov am I missing something here? are there any other alternatives for library developers?
g

gildor

10/18/2018, 10:02 AM
In my library I just have 2 branches one for 1.2 and one for 1.3
o

oshai

10/18/2018, 10:25 AM
ok, thanks
e

elizarov

10/18/2018, 10:29 AM
That is the way to go! With Kotlin 1.3 release around the corner it will be over soon.
o

oshai

10/18/2018, 1:17 PM
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