I intend to try out arrow 2 0 Are there any major pieces mis

Question

I intend to try out arrow 2 0 Are there any major pieces missing broken to watch out avoid ignoring any API stability concerns

simon.vergauwen · Answer

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

Stylianos Gakis · Answer

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 sweat smile

simon.vergauwen · Answer

1 x x gt 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 gt 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>

simon.vergauwen · Answer

So basically all what will change from the last 1 x x version gt 2 x x is removing ` Deprecated` methods and thus breaking the binary

simon.vergauwen · Answer

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 ` gt `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

simon.vergauwen · Answer

Having a strong migration plan is most important I d say

Stylianos Gakis · Answer

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 pray