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.