Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
yellow-dog4743518dThis... was released 2 years ago and isnt a breaking change
d1v1n35h4d0w117dAfter a million brain cell casualty, I imagine you can empathize with the horridness of canBuildFrom.
I teach functional programming over lunch-and-learns, and it was so exasperating to go "this is map: def map[A,B](col: Seq[A], f: A => B): Seq[B]" and then someone looks at the API and finds CanBuildFrom.
Breaking API changes are certainly annoying (sorting on Doubles?), but in general I appreciate the collections API compared to say... R
naitree4317d@yellow-dog It is a breaking change because a lot of `*Like` traits are gone, `Traversable` trait is gone, CanBuildFrom is gone, etc.
Sure, for common collection types (List, Map, etc.) most things ain't breaking. but I'd definitely classify the API change in general as breaking. Otherwise, there's no need for an official migration guide. https://docs.scala-lang.org/overvie...
IntrusionCM233317d@naitree Yes, I can wholeheartedly agree with it.
But on the other hand - when you try to "phase out" an API by deprecating it and keeping it over several versions...
It's bad (TM).
You need workarounds inside the code, you have an butt ugly martian who produces all kind's of additional burden on the code and especially: There will be always one consumer who says "No you can't kill it yet, we still use it" (even after it's been deprecated for > 5 years).
As long as u keep semantic versioning up AND don't do this EVERY FSCKING VERSION - I'm fine with it.
However - if someone releases fast and keeps changing the whole API like a tramp keeps loosing her underwear...
I wouldn't recommend using the library at all, and officially state no support from my side as this has to end in a desaster.