Excuse me if this question has already been asked, but I haven’t found anything about it.
The official documentation says that Plasma 5.27 will be maintained at least until the release of Plasma 6, but it doesn’t seem to me that a decision has been made yet on whether it will be extended.
Is there any news? I think it would be useful to continue maintaining it at least until the next point release.
Thank you.
1 Like
Like always once Plasma 6.0.0 drops it will be end of life for the 5.7 series. Plasma is basically a rolling release so no previous versions are supported.
I don’t think this is correct. There are LTS releases that get longer support.
I haven’t heard anything either. I hope they support 5.27 until the major distros switch to 6.
If there is a decision Schedules/Plasma 5 - KDE Community Wiki should be updated.
1 Like
I have heard something about early February in 2024
Early February is when Plasma 6 drops (scheduled): Plasma/Plasma 6 - KDE Community Wiki
Hopefully and also likely Plasma 5 is supported until the non bleeding edge Distros switch to Plasma 6.
The honest answer is that Plasma 5’s maintenance will stop the moment Plasma 6 is released.
It’s already mostly stopped anyway, to be honest. What “maintenance” means in this context is really just backporting bugfixes. But there are incredible challenges involved with maintaining multiple versions of an OS at the same time. Developing on one while backporting fixes to another one where the code may have changed significantly is unbelievably difficult for a large and fast-moving project like Plasma. The reason is because developers need to maintain a mental model of the entire system they’re working on in their heads to be productive; when you ask them to maintain older releases, what you’re asking is for them to mentally keep two or more of these mental models in parallel. There are tools that can make the interaction with old codebases easier, but nothing can really work around the fact that you need them to double or triple their cognitive burden.
I used to do this kind of thing as part of my day job as a release engineer at Apple Inc. for 7 years. With similarly large and fast-moving software, even with the virtually unlimited resources of the world’s largest tech company, we struggled at the time to properly maintain three parallel releases. As I said, it’s kind of psychologically too much for one person to work on multiple versions of the codebase in a way that really works, so what we did was assign different people to each release–which of course requires a lot of personnel and is extremely expensive. But then you’ve transformed your problem of developers’ excessive cognitive burdens into a problem of communication between teams. This requires managers and management and cross-functional meetings and all the corporate overhead that people love to hate.
Now, it’s been another 7 years since I worked there, so maybe things have gotten better. But still, the point is that it’s hard to overstate the massive amount of resources required to pull off something like this. It’s not intuitive to people who have never done it before, but the challenge is just enormous.
And KDE doesn’t even have a fraction of a fraction of the resources of a company like Apple. As a result we’re mostly limited to developing one release and doing extremely minor and limited basic maintenance for the prior release for cases where the codebase of the old release hasn’t diverged much or at all compared to the new one.
9 Likes
There is no winning there.
Indeed. I think this is a major reason for the popularity of SAAS in the commercial world. Without discrete releases, developers can always be working on what’s effectively git master, reducing their cognitive burden. And with server-side auto-updates, users can’t keep using older versions, where they will then request support and maintenance for them which in practice are almost impossible to provide properly.
While the sentinent behind that statement is generally true there’s a bit of nuance here.
Plasma 5.27 will still be formally supported for a while. The primary aim is keeping it working the way it does now. This means doing security fixes (security issues in Plasma are quite rare), keeping up with relevant changes in dependencies etc.
There will likely be occasional backports of bugfixes from 6.0, but don’t expect that to happen on mass and loads of now existing bugs in 5.27 getting fixed
3 Likes
I understand the difficulties but I think you are a bit too dramatic here. KDE devs did it for several months now. Six months more are not that hell. One point release for security fixes.
Also, you are doing it while you are porting tons of code to QT6, from February to August you will only fix bugs for Plasma 6.
Finally, with 6 months more you give time to third party to adapt plugins, themes etc. so users can switch to Plasma 6.1 with less troubles.
You do understand these folks are volunteers? I’m amazed at what they have managed to do.
1 Like
Plasma 5.27 has already gotten better maintenance and more releases than any prior LTS version in memory. But this was aided by two factors:
- The codebase for Plasma 6 had not yet changed as substantially as it has right now
- Many core developers still had Plasma 5 dev setups active and in use
These factors are less true now, which contribute to fixes for old bugs being harder to backport.
I’m not saying it will never happen again, but I’m trying to set expectations accordingly. After Plasma 6 is released, I don’t expect there to be many or even possibly any more releases of Plasma 5.27. If there are, they will contain extremely minimal changes.
4 Likes
I rest my case for those that questioned me. As for being an OS no Plasma sets on top of a OS.
1 Like
Thanks. I guess supported can mean a lot of things, but this is what I expected and hoped for.
Those who can’t or don’t want to upgrade can still have a functional (not regressing) and secure Plasma 5. That is “supported”, atleast in my opinion.
Those who want major improvements or bug fixes need to switch to plasma 6 anyway.
Indeed, Plasma is a desktop environment, not an OS. An OS is something like Arch, Neon, Ubuntu, Debian, Fedora, OpenSUSE Tumbleweed, etc.
1 Like
I guess distro (e.g. Debian) maintainers will provide that “support” anyway, as long as one of their “supported” releases contains Plasma 5. That doesn’t really depend on KDE developers’ plan with Plasma 5.
And that’s where the support burden should fall for entities (e.g. distributors) who are choosing to freeze the software they distribute at an arbitrary point, rather than continuing to adopt fixes and improvements made upstream. Totally their right to do so, but rights come with responsibilities.
4 Likes
Maintaining support for different old versions is not easy and needs effort, time and money, that’s why many big companies provide long paid support for their old software, and it really works perfectly for them, because some customers are always ready to pay whatever to maintain both stability and security of their complex systems.
1 Like
More likely they will drop 5 support like a hot potato.
SIMPLY NO!!!
If a Distro wants to incorporate 3rd party software they are expected to keep it updated and not block updates to it.