I intend to try out arrow 2.0. Are there any major...

# arrow

[P A]

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]

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]

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 😅

[simon.vergauwen]

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.

[simon.vergauwen]

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.

[simon.vergauwen]

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.

[simon.vergauwen]

Having a strong migration plan is most important I'd say.

[Stylianos Gakis]

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 🙏