4 ms·

> And if that does not work, it is better to release a different library Is that really a solution though? You're just going to end up with an unsupported old

by nawgz 5y ago

> And if that does not work, it is better to release a different library Is that really a solution though? You're just going to end up with an unsupported old version and a supported yet breaking new version which probably doesn't even have upgrade guidance... Not sure I see it. I think libraries should work hard as you say to not break backwards compat, but I also think the library author has the right to change some function signatures when they change major behaviors too

jnxx 5y ago
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.

4 ms·

> And if that does not work, it is better to release a different library Is that really a solution though? You're just going to end up with an unsupported old

by nawgz 5y ago

jnxx 5y ago
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.