5 ms·

A decent explanation, but one part strikes me as odd: > Changing a library's API in a backwards-incompatible way is in general bad form because it means that d

• awalton 10y ago
  Nothing in that comment said you can't do whatever you want - it said, quite specifically, it's bad form to do it, and then explained exactly why that was the case. Plenty of libraries break API/ABI all of the time. Notoriously FFMPEG was/is terrible about it. But depending on libraries that are hugely unstable in this way is terrible, so in most cases, people go out of their ways to avoid doing so (most frequently using another library, or in harder-to-avoid cases creating an interposer library to smooth out the instabilities of the underlying library). OSS developers probably know more than anyone in the world that the most expensive thing to do in software engineering is maintaining a piece of software as time moves forward. Anything that makes that job more difficult needs to have an enormous upside to make it worth while, and in almost every case, using an unstable library is just not worth the extra maintenance costs attached.
  • tener 10y ago
    All true, but for some reason he sees the major libraries as a different beast and I just don't see why, which is why I wrote it strikes me as odd.
    • curryhoward 10y ago
      I think you are interpreting it as "Major libraries are allowed to do it sometimes." I think what he meant to say is "Even major libraries do it sometimes." It is already understood that minor libraries do it.
    • crpatino 10y ago
      I read it as: major libraries are reluctanly tolerated to break their API/ABI now and then. They are different beasts, whether you like it or not. A colorary to the above is: libraries that break their API/AIB too early or too ofter never get a chance to earn the 'major' label in the first place. You could also argue that a major library that abuses their privilege and breaks backwards compatibility beyond their "karma ballance" will be eventually forked or otherwise replaced by a more stable competitor. I am not sure if this idea holds water in the real world, but I really hope it does.
• ctack 10y ago
  I read it as "it's bad form, although it has been known to happen."
• Chickenosaurus 10y ago
  He is not saying that the "big guys" are allowed to break APIs. He is remarking that in the case of major libraries, they break APIs. Thats simply an observation, nothing else.
  • tener 10y ago
    Ah this is possible, but then this observation seems limited to me as smaller libraries break APIs too.
    • chme 10y ago
      The API break of Gnome 2 to Gnome 3 and KDE 3 to KDE 4 etc. are just more commonly known than those of some small library. So it is just a good example.
• astrodust 10y ago
  A major system like that can't shift very often because if it changes even slightly it brings down a proverbial house of cards built on top of it. Little inconsequential libraries can move fast and break things, though there's a peculiar paradox here. As the number of dependencies grows, the tolerance for change decreases, yet in terms of perception, little libraries that aren't major dependencies that change frequently look untrustworthy and are liable to never be trusted because of their flux. That is, if you want to be successful, be predictable and consistent even if that means being leaving some potential unrealized.
• ascotan 10y ago
  That's because you can simply add functionality and increase the minor version of the library. If you change the first digit you have removed or modified an interface. The same can be said about an API. Most API developers don't delete an API call or change the POST params on working code, they simply add a new function.