'KDE Plasma LTS Releases Are Dead' (itsfoss.com) 29
With its Start menu-style application launcher and its bottom-of-the-screen taskbar, KDE Plasma is a "nice" and "traditional" desktop environment that's "also highly customizable," notes It's FOSS News.
But there's a change coming... In contrast to other desktop environments, KDE offers a long-term support release (LTS) of Plasma, where bug fixes and security updates are provided for an extended period, with no new major changes being introduced. However, that is no longer the case now. Shared by Nate Graham, a prominent contributor within the KDE community, KDE has decided to stop working on LTS releases of Plasma, shifting its focus on extending support for the bug-fix and feature releases instead.
The reasoning behind this move is multi-faceted, with factors such as inconsistent expectations from the community, developers' reluctance to work on older versions, and the lack of consistency in LTS support for Frameworks and Gear apps... I believe this move will provide Plasma users with a better Linux desktop experience, thanks to the extended bug-fix period, which will enhance the stability of each release.
From Graham's blog post: It's no secret that our Plasma LTS ("Long-Term Support") product isn't great. It really only means we backport bug-fixes for longer than usual — usually without even testing them, since no Plasma developers enjoy living on or testing old branches. And there's no corresponding LTS product for Frameworks or Gear apps, leaving a lot of holes in the LTS umbrella. Then there's the fact that "LTS" means different things to different people; many have an expansive definition of the term that gives them expectations of stability that are impossible to meet.
Our conclusion was that the fairly limited nature of the product isn't meeting anyone's expectations, so we decided to not continue it. Instead, we'll lengthen the effective support period of normal Plasma releases a bit by adding on an extra bug-fix release, taking us from five to six.
We also revisited the topic of reducing from three to two Plasma feature releases per year, with a much longer bug-fix release schedule. It would effectively make every Plasma version a sort of mini-LTS, and we'd also try to align them with the twice-yearly release schedules of Kubuntu and Fedora.
However, the concept of "Long-Term Support" doesn't go away just because we're not giving that label to any of our software releases anymore. Really, it was always a label applied by distros anyway — the distros doing the hard work of building an LTS final product out of myriad software components that were never themselves declared LTS by their own developers. It's a lot of work.
So we decided to strengthen our messaging that users of KDE software on LTS distros should be reporting issues to their distro, and not to KDE. An LTS software stack is complex and requires a lot of engineering effort to stabilize; the most appropriate people to triage issues on LTS distros are the engineers putting them together. This will free up time among KDE's bug triagers and developers to focus on current issues they can reproduce and fix, rather than wasting time on issues that can't be reproduced due to a hugely different software stack, or that were fixed months or years ago yet reported to us anyway due to many users' unfamiliarity with software release schedules and bug reporting.
But there's a change coming... In contrast to other desktop environments, KDE offers a long-term support release (LTS) of Plasma, where bug fixes and security updates are provided for an extended period, with no new major changes being introduced. However, that is no longer the case now. Shared by Nate Graham, a prominent contributor within the KDE community, KDE has decided to stop working on LTS releases of Plasma, shifting its focus on extending support for the bug-fix and feature releases instead.
The reasoning behind this move is multi-faceted, with factors such as inconsistent expectations from the community, developers' reluctance to work on older versions, and the lack of consistency in LTS support for Frameworks and Gear apps... I believe this move will provide Plasma users with a better Linux desktop experience, thanks to the extended bug-fix period, which will enhance the stability of each release.
From Graham's blog post: It's no secret that our Plasma LTS ("Long-Term Support") product isn't great. It really only means we backport bug-fixes for longer than usual — usually without even testing them, since no Plasma developers enjoy living on or testing old branches. And there's no corresponding LTS product for Frameworks or Gear apps, leaving a lot of holes in the LTS umbrella. Then there's the fact that "LTS" means different things to different people; many have an expansive definition of the term that gives them expectations of stability that are impossible to meet.
Our conclusion was that the fairly limited nature of the product isn't meeting anyone's expectations, so we decided to not continue it. Instead, we'll lengthen the effective support period of normal Plasma releases a bit by adding on an extra bug-fix release, taking us from five to six.
We also revisited the topic of reducing from three to two Plasma feature releases per year, with a much longer bug-fix release schedule. It would effectively make every Plasma version a sort of mini-LTS, and we'd also try to align them with the twice-yearly release schedules of Kubuntu and Fedora.
However, the concept of "Long-Term Support" doesn't go away just because we're not giving that label to any of our software releases anymore. Really, it was always a label applied by distros anyway — the distros doing the hard work of building an LTS final product out of myriad software components that were never themselves declared LTS by their own developers. It's a lot of work.
So we decided to strengthen our messaging that users of KDE software on LTS distros should be reporting issues to their distro, and not to KDE. An LTS software stack is complex and requires a lot of engineering effort to stabilize; the most appropriate people to triage issues on LTS distros are the engineers putting them together. This will free up time among KDE's bug triagers and developers to focus on current issues they can reproduce and fix, rather than wasting time on issues that can't be reproduced due to a hugely different software stack, or that were fixed months or years ago yet reported to us anyway due to many users' unfamiliarity with software release schedules and bug reporting.
LTS's are obsolete (Score:1)
Re:LTS's are obsolete (Score:5, Insightful)
Spoken like someone who has never worked in corporate IT.
Sometimes stability is important, and having developers "move fast and break things" is the last thing you want.
Re: (Score:2)
Spoken like someone who has never worked in corporate IT.
Agreed!
Also spoken as someone who is young and hasn't had to waste a significant period of his life on needless upgrades, or who lives on his computer (or in his mother's basement or both).
I use LTS because I want my software to work and to work for longer than the day I install it. I sue LTS because I have better things to do than chase down upgrades or live on the bleeding edge of essentially a rolling GIT release of my whole system because some developer decides that my desktop can't live without a libr
Re: (Score:3)
I use LTS because I want my software to work and to work for longer than the day I install it.
That's perfectly reasonable. Now what's your plan to have this funded? Best I can suggest is for everyone in this room to buy suse.com support subscriptions, then they might have extra money to support another KDE maintainer.
Re: (Score:2)
.... Along with sufficient time and sufficient ability.
If I had unlimited time and unlimited ability, I wouldn't even need the source, I would write everything myself from scratch.
Firefox doesn't care about the browser (Score:2)
All the browser need do is exist to get Googlebux, but instead of putting their revenue into the browser and Thunderbird, Mozilla chose to enrich their buddy network on unrelated garbage.
There is no support burden remotely close to Mozilla revenue.
Re:LTS's are obsolete (Score:4, Insightful)
They're not obsolete, just not trendy because stability and predictability are tired and moving fast and breaking things (that people rely on) are wired.
Honestly, the attitude you're promoting sucks and it's part of why everything's been enshittified and continuing to be enshittified. I don't want monthly releases of anything but bug fixes. I want stability, and predictability. I'm tired of our industry insisting going in the other direction.
LTS releases are the rare glimmer of sunlight in this broken dystopian computing environment, where sane rational people actually have at least a temporary escape from all this bullshit.
Re: (Score:2)
I don't want monthly releases of anything but bug fixes.
Oh god I do. There's not a single piece of software I have ever used on any platform that has been perfect to the point where it couldn't have benefitted from feature improvements.
That said I fully support having two release schedules. Stability is important for money making enterprises. But I want to point out that many people don't think like you which is precisely why move fast and break things is the mantra of the day - it makes money and consumers love the idea that their software may be ever improving
Re: (Score:2)
So my question is, how does the end user in anyway benefit from 8-weekly releases?
Security fixes are one thing but I can't remember the last time a web browser implemented a killer feature necessitating an upgrade. (e.g. this month's release highlights scanned pdfs, functionality I never asked for)
Your fave websites aren't going to die because you don't upgrade; programmers tend to be fairly conservative with their frameworks - you don't want bleeding edge that doesn't work on Safari, Edge or Firefox.
Due to.. (Score:2)
Re: (Score:2)
Kubuntu and Neon (Score:3)
Depending on what 'extended support' is going to mean I might look a Neon with it's rolling release schedule.
This is the challenge of FOSS (Score:5, Interesting)
This is, unfortunately, the largest challenge of FOSS. Developers who work on it for the love of it are often disconnected from normal users, and, well let's call a spade a spade, from reality in general.
Developers on FOSS often write because it's something they want to use. Which is ok, but a developer/power user has very different needs, wants, and skill level from the general class of users. You want to know why the "Year of the Linux Desktop" is so cliche a joke, that's why. That's why right there. Users don't enjoy living on the bleeding edge. They want and need it to just work, and to work for a longer period of time than the day they install it.
No one wants to have to operate a bleeding edge development rig to RUN this shit.
Jesus... are you actively trying to get distros to drop your product? This is how to do it:
- Step one, blame the user for not wanting a rolling-release home-built Linux From Scratch via Git rig.
- Step two, pawn off the responsibility for maintaining YOUR software to the distributions. Because the volunteers at Debian who package this want to have to know your software better than your own developers and have so much extra time.
- Step three, watch the distros you are giving the finger to run and your adoption tank.
KDE already has a far lower uptake, and is declining. There's a reason that Mint never released a KDE version. Maybe this is just KDE's way of ceding the user-space market they are losing anyway, and to focus only on the bleeding-edge crowd. I just feel bad for normal users who get sucked into KDE not knowing it's a mine field.
Re: (Score:2)
Correction, Mint had KDE and dropped it with Mint 19. Which, actually, makes my point.
Re: (Score:2)
You have good points but you also go into caricature. Nobody expects KDE users to run from git. KDE releases monthly bugfixes an a new Plasma version every 4 months. I don't know why you would call KDE a minefield. It works great.
Re: (Score:3)
Re:This is the challenge of FOSS (Score:4, Informative)
Not that QT wasn't open source enough, quite the opposite. QT was under a copyleft license without a library linking exclusion clause, first a custom license, and then the (regular, non-L) GPL. (by comparison GTK+ was LGPL from the beginning.) As a result non-open source software couldn't be written to use the KDE environment without paying a license fee to Trolltech. And software licensed under a license incompatible with the GPL, such as Mozilla, had problems too.
Long after everyone went GNOME, Trolltech relicensed QT, starting with QT 4.0, under a variety of licenses with exemptions to allow for, say, MPL interoperability, but at that point it was too late.
None of this was "FUDD" (what's the extra D?) or "fearmongering", it was a straightforward case of the license being impossible to reconcile with the intended use case. Despite the ultimate goals of wanting to produce an open source ecosystem, some software is always going to be proprietary, and even some copy left software isn't going to be licensed under something compatible with Trolltech's pre-QT4 licenses.
Re: (Score:2)
"Developers who work on it for the love of it are often disconnected from normal users"
There seems to be a decent fraction of them that take Linux as the ultimate computer game. That's well and good for them and KDE seems to have more than its share of them "because it's so customizable."
Paralysis from too many choices is a thing. I have work to do or I wouldn't be on the computer. For goofing off online the iPad worked better if only because the chair is more comfortable.
For the record the "work" computer
That's why maintaining legacy stacks ... (Score:2)
... should be its own form of cherished FOSS work. That's the beauty of FOSS. That's why projects like the Mate Desktop environment should get as much ongoing attention as all the newfangled stuff. I still miss some features from the old KDE Konqueror file manager for instance.
"Importance" vs "Interesting" (Score:3, Insightful)
One of the real issues in open-source software (referenced above) is the fact that you can't really force unpaid volunteers towards tasks that are uninteresting, such as maintaining years-old software that might not be heavily used. Maintaining LTS releases is definitely important but not necessarily interesting. And finding that balance to keep volunteers helping can be very tricky.
Even Microsoft struggles with this: Part of the reason they made Windows 10 free were the costs associated with having to maintain however many flavors of Windows 7 and 8 and 10; better to get everyone on 10 and make their lives easier.
There are no easy answers and we shouldn't be quick to condemn KDE if you are not also willing to help maintain older releases.
Stability through reckless change (Score:3)
So, they're turning their backs on LTS support, so they can innovate faster than ever before.
Yeah, I'm sure that will further their goal to, "...enhance the stability of each release."
Maybe they need another maintenance fork. (Score:2)
I'm happily using TDE (Trinity Desktop Environment), because KDE3.5 has the features I need and have built up my work habits around, and Trinity is the maintenance fork preserving and enhancing it. (My particular layout uses an external taskbar up top and a window-selector in the panel-bar at the bottom so I can get at things quickly, the same layout I got used to in KDE1.1 on RHL6.2. Plasma, when I tried it out, didn't support that, so I turned around and didn't look back. YMMV; that's what works for me.)
I
There is no good point to them (Score:2)
I am a huge fan of software that doesn't have huge changes often. But the Plasma desktop has a very stable user experience. I am really happy about each update, there is always something getting better even in the small details, but the last revolution was between KDE 4 and 5, afterward it got only more polished and stable. There is no need for an LTS, if your usual releases do not break things. The only point is that distributions like Debian, which like to stick with older versions, have it easier to patc