https://kotlinlang.org logo
Title
p

P A

02/02/2023, 8:33 PM
I intend to try out arrow 2.0. Are there any major pieces missing/broken to watch-out/avoid(ignoring any API stability concerns)?
s

simon.vergauwen

02/03/2023, 8:57 AM
Nothing is broken, and no major pieces are missing. We're currently in the process of back-porting changes, and we're nearly complete. So when the outstanding work in the PRs get merged than almost everything available in 2.x.x will be available in 1.x.x.
s

Stylianos Gakis

02/06/2023, 5:09 PM
When this happens, what purpose will the 2.0 release have? Not downplaying it, just trying to understand as someone who has never made a library nor library versioning decisions 😅
s

simon.vergauwen

02/06/2023, 5:13 PM
1.x.x -> 2.x.x will basically mark a binary breaking change, so projects compiled with 1.x.x might result in
ClassNotFoundException
, etc or other kinds of errors when using it from a 2.x.x project. Same reason Kotlin puts on
@ExperimentalTime
, they changed the binary in
TimeSource
from 1.6 -> 1.7 and for exampling when you using
TimeSource
in a 1.7 or 1.8 project with the current Kotest (compiled with 1.6) it results in https://github.com/kotest/kotest/issues/2960.
So basically all what will change from the last 1.x.x version -> 2.x.x is removing
@Deprecated
methods and thus breaking the binary.
There is two trains of thoughts for library development: • Keep things
@ExperimentalXXX
for several years, and potentially breaking binary across minor versions. Which is for example what Kotlin did in the
1.6.
->
1.7
version for
TimeMark
. • Evolve the APIs by introducing non-conflicting method names, or new packages. Deprecate old code, and bump major version. Which is what Kotest, Arrow, etc does. I think this is the more common approach. I think it makes sense what Kotlin does, and I thought about doing the same thing for
arrow.core.continuations
2-3 years ago but it might've also been really annoying having all of this stuff as
OptIn
. It's hard to say which one was better, I think we have a pretty good forward migration roadmap so that it's not an issue and in the end it wouldn't have made a huge difference which road we would've taken.
Having a strong migration plan is most important I'd say.
s

Stylianos Gakis

02/06/2023, 7:49 PM
Okay so it's gonna be the cleanup that sweeps all those existing parts that are there purely for backwards compatibility. Originally I was just thinking if all of the 2.0 functionality is backported to 1.x what was the point? But this makes sense to me, thanks 🙏