alt Hacker NewsAs someone who shipped my fair share of critical production features, I find this plan raising my eyebrows somewhat. Disabling a feature AND simultaneously removing the codebase for that feature almost never ends well. There will always be some use cases that people haven't thought of.
In serious projects (read, your career is at stake) a much better strategy is to first make the feature unavailable by normal means while still allowing a workaround (in this case, for example, PLM could remove X11 option from the menu but still allow X11 sessions when some magic environment variable is set.) That would give people an easy way to get the old functionality if something is critically impaired for them. And only then, once we are confident that no massive unforeseen issue has surfaced, can the codebase be removed.
Replies
The problem with that strategy when it comes to desktop software is there's no way for the developer to know what the user has done (unless the software phones home, which is a no-no when it comes to privacy-respecting open source software).
If it's a SaaS API or a web application, the developers can look at access logs or analytics to determine what endpoints and features are being used, and when users need to go back to the deprecated interfaces to get what they want.
There's no way for a KDE developer to learn "$NUMBER users went back to X11 because $FEATURE is missing in the Wayland version".
(Of course they can ask their users, or hope that users file issues on the bug tracker, but things will definitely fall through the cracks via these imperfect communication channels.)
That is quite literally exactly what they have done
Time to fork and move on...
> a much better strategy is to first make the feature unavailable by normal means
They started doing that in early 2024 with the release of KDE 6.0 by enabling KDE Wayland by default. The Wayland-only change won't happen til 6.8 which will be an early 2027 release.
https://pointieststick.com/2023/11/10/this-week-in-kde-wayla...
> And only then, once we are confident that no massive unforeseen issue has surfaced, can the codebase be removed.
Yes, that's the current step they'll be at with 6.8.