4 ms·

"support" means two things. On the one extreme end, it means "provide commerical support for a product", on the other end it means "permit it to happen". I woul

"support" means two things. On the one extreme end, it means "provide commerical support for a product", on the other end it means "permit it to happen". I wouldn't support anything in the first sense, but if I would maintain a popular package I would strive to support as much as possible in the second sense. In my experience, keeping code general and cross platform is a great way to ensure correctness. Especially in C(++). I can't count how many bugs I caught by cross compiling Linux code on Windows, or with different compilers, or different architectures. Usually the kind of sleeping bug due to undefined behavior or wrong assumptions that kind of worked but might blow up a long time later. In most projects, if somebody provides a small patch to make my code work for their use case, and it's not too much trouble for me, and my tests pass, then I'll gladly include it. I'll not "support-support" it, but I think one should support it. At least if I open-sourced it because I want it to be useful to other people.

roxgib 4y ago
Many (most?) projects bypass this by simply not specifying which platforms are supported, and making decisions about breaking support on an ad hoc basis. Of course OSS developers are entitled to do this if they think it's best, but that's a good way to either create a burden for yourself when people start using your package in unintended ways, or to annoy people when something suddenly stops working because you never intended to support it. Rust is doing it right by explicitly stating which targets are supported and to what extent. You can use it for other targets (I've written a lot of code for AVR which isn't supported at all) but if something breaks they stated up front that it wasn't supported.