Consider klock dependency. about reaktive HOT 9 CLOSED

Copy few classes into com.badoo.reaktive.utils.time.
For now, when native and metadata are not stable yet, we can get situation, when external dependency will use different version of metadata or Kotlin and we will be blocked by it.

But if we copy then clients will see both variants if they are using klock as well.

Both variants of 2-3 classes? With different packages? Not a big deal.

from reaktive.

Isn't it be better to copy few klock classes to the com.badoo.reaktive.utils.time package instead of making Reactive dependent on external library?
klock code is dual licensed under MIT and Apache 2.0 and we can mention the author.
But I'm not so familiar with possible legal issues.

from reaktive.

One more thing, if depend then Reaktive's Kotlin version must be same as in klock, to be able to build K/N part.

from reaktive.

But if we copy then clients will see both variants if they are using klock as well.

from reaktive.

FYI Kotlin 1.3.50 will offer us experimental date-time classes in standard library
https://github.com/Kotlin/KEEP/blob/durations/proposals/stdlib/durations-and-clocks.md

from reaktive.

FYI Kotlin 1.3.50 will offer us experimental date-time classes in standard library
https://github.com/Kotlin/KEEP/blob/durations/proposals/stdlib/durations-and-clocks.md

We want to release stable version very soon, changing public API without any critical reason will not be possible.

from reaktive.

@lukaville @mk-jones What do you think guys?

from reaktive.

I would better wait for Kotlin 1.3.50 with its Duration in stdlib. But it will block our release... Should we release RC1? And then stable version with Duration and Kotlin 1.3.50?

from reaktive.

Closing the issue due to inactivity, looks like not relevant anymore. Feel free to reopen if needed.

from reaktive.