Update to kotlinx-coroutines 1.2.2 and kotlin 1.3.41

[johnjohndoe]

Description

• I prepared an update to the next version of kotlinx-coroutines.
• I have chosen kotlinx-coroutines 1.2.2 and the kotlin 1.3.41 since kotlinx-coroutines 1.2.2 has a transitive dependency to kotlin 1.3.40.
• I also documented the changes in the dependency tree in the commit messages (see below).

Releasing

• I suggest releasing this update as ru.gildor.coroutines:kotlin-coroutines-retrofit:2.0.0 to allow users to update gradually.
• The next version - kotlinx-coroutines 1.3.2 - should be released as ru.gildor.coroutines:kotlin-coroutines-retrofit:3.0.0 later on.

Commits in order

• Use kotlinx-coroutines-core v.1.2.2.

  • Changelog: https://github.com/Kotlin/kotlinx.coroutines/blob/master/CHANGES.md#version-122
  • Updates in the dependency tree:

    org.jetbrains.kotlin:kotlin-stdlib:1.3.21 -> 1.3.40
    org.jetbrains.kotlinx:kotlinx-coroutines-core:1.2.2
    -> org.jetbrains.kotlin:kotlin-stdlib:1.3.40

• Use kotlin 1.3.41.

  • Changelog: https://github.com/JetBrains/kotlin/releases/tag/v1.3.41
  • Updates in the dependency tree:

    org.jetbrains.kotlinx:kotlinx-coroutines-core:1.2.2
    -> org.jetbrains.kotlin:kotlin-stdlib:1.3.40 -> 1.3.41

[gildor]

why do you think that we need 2.0.0 for coroutines 1.2.2

As I mentioned above, I would instead release 2.0.0 with deprecation of existing await() methods

[johnjohndoe]

In general, I don't think that it's a valuable change. Retrofit now have <T : Any> Call<T>.await() extension ...

Thank you for pointing this out. I haven't realized that Retrofit meanwhile provides the extension functions itself. If I see correctly they are available since version 2.6.0 (?)

... and it's time to deprecate this lib. I will update Readme and probably publish library with deprecated methods ...

I agree that this is a useful step to notify users of your library so they know that they can update their setup.

why do you think that we need 2.0.0 for coroutines 1.2.2

That is a personal style which I apply for my libraries. Anytime I update an external dependency such as kotlin or coroutines I choose a "pessimistic" version. This allows me to publish a minor or bugfix version for my library (which depends on coroutines 1.1.1 following the example). With that any project which uses my library has the freedom to update to the minor or bugfix version or jump to the major version - at their own pace. Since I cannot predict if these projects are always able to jump to the next bigger kotlin or coroutines version I am trying to make their life as comfortable as possible. A similar example would be the Support Library used in Android library projects.

:x: With that I think we can close this pull request.

[johnjohndoe]

... Retrofit now have <T : Any> Call<T>.await() extension ... ... I would instead release 2.0.0 with deprecation of existing await() methods ...

Does that mean you would use retrofit2.await() and kotlin.Result internally and still continue providing ru.gildor.coroutines.retrofit.Result, ru.gildor.coroutines.retrofit.awaitResult and ru.gildor.coroutines.retrofit.getOrDefault via this library as not deprecated?

[johnjohndoe]

I updated my project meanwhile. Thanks for your help. I am closing this PR now.