You can just fold the old interface with the old semantic into a special case of the new interface, and provide a wrapper function with the old signature. This

You can just fold the old interface with the old semantic into a special case of the new interface, and provide a wrapper function with the old signature. This avoids code duplication. > I also think the library author has the right to change some function signatures when they change major behaviors too When the the semantics change, it is already a backwards-incompatible change anyway, so it is cleaner to provide an extra function name for that new version. There might be extreme cases where it is not possible or desirable to keep backwards compatibility, such as hardware bugs in Intel CPUs speculative execution, or APIs which turn out to be so thoroughly botched that they cannot be made safe. But these are exceptions. One thing is to compose from backwards-compatible components makes it much much smother and easier to upgrade to new versions in a system which has many components. Paradoxically, it makes upgrading easier, and this is what library authors ultimately really want from users. While breaking compatibility does not only leads to a rat-tail of consequential breakage and forced upgrades which leads to more breakage, and makes everyone hesitant to do even small upgrades, ensuring backwards-compatibility leads to people upgrading without fear that they are interrupted for weeks and months.