bye bye backwards compatibility
Backwards compatibility is sometimes nice, but it too often leads to
messy code trying to support too much.
ifdefs litter the source code,
snippets that will only get run on hardware that was considered vintage
in the 70s. Why do we need to support this stuff now?
My personal belief is that if you're running a niche hardware or software configuration, you should have accepted the challenges that will come from that and be willing and experienced enough to sort and maintain it yourself. Create a fork - not because you hate the project, but because you love it. It's easier for a project to thrive when its codebase is easy to understand.
Keeping in legacy behaviour "just in case" isn't a valid reason for doing so. At least Apple had the "courage" to remove the headphone jack (which I totally don't agree with, but that's not the point) - when Microsoft removed the double click in the top left of the title bar to close the window functionality, they got so much backlash in testing that they added it back. It's still there, in Windows 10. But whenever I use a Windows system it frustrates me, because some applications override the default decorations (read: browsers) and either don't know about this functionality or don't think it's worth implementing it. I go to close the window and it fullscreens itself. What?
I actually discovered this feature by accident. It's no longer the documented way of closing windows, so probably causes most people under the age of 30 panic or confusion if they do it by mistake.
AwesomeWM causes its users frustration by making breaking changes to its configuration regularly. This isn't the best, but I think that it's definitely better than trying to support multiple configuration formats, and it's also good to improve something if possible. If this means making breaking changes, so be it.
I didn't have much time to write today, but I think I'll explore this topic again at some point in the future. Bye bye :)
October 16, 2019