On Backward Compatibility

When I used to develop a certain CMS / framework, backward compatibility was a holy grail for me. If I wanted to change a function, I would make sure it still accepted former order and type of arguments. Instead I changed it in a way that the function proceeded based on the number and type of arguments received.

Former example (v 1.x):

function process(string $name, int $color, int $size, int $margin) { ... }

Later example (v 1.y):

function process(array $box) { ... }

Nowadays, most of the developers forsake backward compatibility for agile development thus leaving its user (developer) base behind. Change or perish. Rewrite your program based on the functions changed or update and find your software broken (or don’t update and let it rot with vulnerabilities popping up).

Indeed, one can not expect API to stay the same or functions not to change between “big” versions. But changing basic functions without keeping them backward compatible means you don’t care about your library being used and rather program for your own needs. Fair enough, but maybe mention this in the docs, so we can move along long before starting anything based on your public Github repo.

This rant goes to the authors of LÖVE breaking everything that used color, i.e. everything. I still love the simplicity of LÖVE, though. But common, guys, switching from 0-255 to 0-1 without having backward compatible system?!