When a developer is writing a library, main concern is always making it feature complete. But when the developer releases first version to the public, it raises question if any change in the library can alter the existing API.
Essentially whenever developer changes return value, number of parameters, default parameters or parameter types of a function, it breaks API compatibility.
Changing total size, number or order of struct members, or underlying type of a variable also breaks compatibility.
Changing member variables or non-static class methods will also break compatibility as it will change the storage size of the class and its virtual table containing all the member functions of the class itself and classes it inherited from.
So one might ask why is this a bad thing...
It's a bad thing when another developer tries to make a program that uses the library and because of the breakage in API compatibility, the program starts to crash or just stops working, because right callback function doesn't get called anymore.
Not all programming languages have strict type checking and as such try to convert mismatched variable types. When they can't, they try to invoke error handler. If API signature for the error handler is also changed, the error handler doesn't get called and the application will crash and sometimes print stack trace.
If the program is set up as running as a background process, it will most likely try to restart itself when it crashed and if the library is for networking application, it might repeatedly try to reconnect to a host and flood it with short connections.
