4 ms·

"Breaking change" means it changes existing behavior. As in I used to get 'banana' when I passed 'b' and now I get 'bicycle'. If I still get 'banana', you didn'

• hansvm 3y ago
  It sounds like we agree.
• layer8 3y ago
  No, a breaking change is if the interface contract changes in a non-backward compatible way. If the interface contract never promised you to get “banana”, and you still relied on that behavior, then yes your client code may break, but that’s on your side of the program, and your fault for relying on unwarranted assumptions, and not a breaking change in the library you called. The purpose of interface contracts is exactly to precisely specify what can change and what can’t change without breaking clients, and conversely which assumptions clients can or can’t make. This is a precise give and take. The clients are expected to play by those rules just like the implementations of the interface are expected to maintain their promises — nothing more, nothing less.
  • camgunz 3y ago
    This is an academic definition. In a system with dependencies, if you change behavior your dependents relied on, you broke them. If you didn't, you didn't. In other words, if you break prod, "but we never promised to behave this way" is a poor excuse. When changing something, it's your responsibility to check for breakage, not just throw up your hands and say "not our fault" if it occurs.
    • kazinator 3y ago
      E.g. a number of years ago now someone in Glibc development thought it would be fine to change the behavior of memcpy for overlapping objects. Nobody does that, right? It's undefined behavior. Downstream distros broke; it had to be backpedaled out.