3 ms·

Depends on your choice of language and framework etc though? The js ecosystem is very break-y and, at least when I worked with it, so was the Ruby/RoR ecosystem

Depends on your choice of language and framework etc though? The js ecosystem is very break-y and, at least when I worked with it, so was the Ruby/RoR ecosystem. In .net or Java, far less so; we have almost 10 year old software which we can update the libs off and it compiles and runs the tests just fine.

thayne 4y ago
Even Java broke things between java 8 and 9
- haimez 4y ago
  With flags to recover the previous behavior, and the changes of which only broke code using non-public API surface, i.e.: code that should never have been using those APIs but which previously had no way to prevent usages.
  - thayne 4y ago
    > With flags to recover the previous behavior I'm not sure what flags you are referring to, but that might be because I went from 8 to 11 and skipped 9 and 10. > the changes of which only broke code using non-public API surface The APIs weren't non-public. They were publicly documented. They did say they were internal and you should avoid them, but they were still used in libraries and referenced in tutorials and stack overflow answers. And if you happened to transitively use a library that used one of those APIs, it would cause a fair amount of pain when you upgraded.
    - haimez 4y ago
      They were non-public, at least all the ones that I recall being broken (from memory, but let me know if I’ve missed something important here: URLClassLoader, Base 64 classes (made public under a different name), unsafe: name implies the contract to some extent, but also still available under a flag. Then there’s the whole slew of things like DNS resolvers that override internal classes, but again- weren’t supposed to be for “public” consumption. Ultimately, the break seems to have been intentional, but did receive appropriate consideration. Mark’s comments about moving forward do address these points.
  - josefx 4y ago
    Modularization "broke" a few public APIs since they had to remove an interface declared in swing from some classes outside of the package. I am not sure if there is even one known case of anyone being affected by that change.

thayne 4y ago

Even Java broke things between java 8 and 9

haimez 4y ago
With flags to recover the previous behavior, and the changes of which only broke code using non-public API surface, i.e.: code that should never have been using those APIs but which previously had no way to prevent usages.
- thayne 4y ago
  > With flags to recover the previous behavior I'm not sure what flags you are referring to, but that might be because I went from 8 to 11 and skipped 9 and 10. > the changes of which only broke code using non-public API surface The APIs weren't non-public. They were publicly documented. They did say they were internal and you should avoid them, but they were still used in libraries and referenced in tutorials and stack overflow answers. And if you happened to transitively use a library that used one of those APIs, it would cause a fair amount of pain when you upgraded.
  - haimez 4y ago
    They were non-public, at least all the ones that I recall being broken (from memory, but let me know if I’ve missed something important here: URLClassLoader, Base 64 classes (made public under a different name), unsafe: name implies the contract to some extent, but also still available under a flag. Then there’s the whole slew of things like DNS resolvers that override internal classes, but again- weren’t supposed to be for “public” consumption. Ultimately, the break seems to have been intentional, but did receive appropriate consideration. Mark’s comments about moving forward do address these points.
- josefx 4y ago
  Modularization "broke" a few public APIs since they had to remove an interface declared in swing from some classes outside of the package. I am not sure if there is even one known case of anyone being affected by that change.