Who’s responsible for bug reports on old software versions?

https://lobste.rs/rss Hits: 15
Summary

Consider this hypothetical: An operating system (OS) ships version 1.5 of a piece of software. Meanwhile, the latest version of that software is 3.0. A user on that OS experiences an issue in version 1.5, or has an idea for a new feature. Who should they contact? This hypothetical becomes concrete due to the existence of discrete-release OSs, like Ubuntu, Debian, openSUSE Leap, and Linux Mint. These intentionally freeze on certain versions of the software they ship for a certain period of time — even if newer versions have already been released upstream of them. It’s in the news right now because of a recent kerfuffle over in Linux Mint specifically; a developer of GNOME Calendar asked Linux Mint to patch out support links and change the branding, and later followed up with a fairly inflammatory blog post after the issue was locked for understandable reasons. This saddens me because the miscommunication was preventable, and now a good portion of the discussion surrounding the topic is about tone rather than the topic itself — a predictable outcome of not caring about tone. But I digress. I think it’s an important topic, so I thought I’d share my take on the situation. Are software developers responsible? Software devs wrote the software. The software broke. End of story. If only life were that simple! Having been on the receiving end of thousands of un-actionable bug reports about old versions of KDE’s software in discrete-release OSs for issues that were fixed months or years ago (but not backported by the OS distributor!)… I can tell you it’s very frustrating. But we in the free, open-source software (FOSS) world make our software available via free software licenses; we need to be prepared for OSs distributing our software in ways we didn’t anticipate or aren’t thrilled about, and bug reports from their users. That’s life. Our solution in KDE is a bot that automatically closes bug reports for versions of Plasma that are out of support, and we may eventually broad...

First seen: 2026-07-20 02:55

Last seen: 2026-07-20 20:16