I use Arch-linux which employs Rolling Release model.

Some significant instability issue might occur on the cutting-edge package updates of Arch, so recently, I start using `linux-lts` for kernel instead of the default `linux` package.
In my experience, linux GUI environment tends to be easily broken, and I'm very happy to hear KDE project releases their first Long-Term-Support edition for Plasma.

https://community.kde.org/Schedules/Plasma_5
According to the planned release schedule for Plasma 5, the 5.9.0, that is non-LTS will be released on 2017-01-31, but I simply want to stick to 5.8.*-LTS until the next Plasma-LTS release for the most concerned GUI stability of the system.

So, I posted in Arch mailing-list on this issue:
https://lists.archlinux.org/pipermail/a ... 42567.html
however, many reacted negatively for KDE Plasma LTE package on Arch rolling release model.

Their opinion is:

>Well, first “affected by dependency issues arising from version
mismatches (like soname bumps)”. So every time something that any
plasma-lts package depends on require an ABI bump, you have to recompile
things. You might say, devs have tools to do so quite automatically.
Yes, but what if plasma-lts doesn’t build with the new libwhatever? Will
plasma-lts have updates that take care of this? Will they be available
ahead of libwhatever release?
>Then, consider the number of package plasma-lts represents. Multiply by
their number of dependencies. Especially, kframeworks will continue
moving ahead. Will compatibility with newer versions be assured? I’m not
quite sure, since I don’t see why you would use lts plasma with latest
frameworks.
>And that’s only one thing I can think of on the top of my head.
>So, lot of maintenance burden, for quite no gain.

or
>What's completely missing by the kernel related explanation is, that
upstrem provides, IOW maintains longterm linux,
https://www.kernel.org/ . Does KDE upstream maintain KDE Plasma LTS?

>>Ralf, exactly, and that is to what I'm attracted.
>>https://community.kde.org/Schedules/Plasma_5

>That they maintain it doesn't necessarily mean that they will also make
sure that it works with new library versions. It sounded more like bug-
and security fixes to me.
>Arch is not like Debian or even Ubuntu. Most libraries get updated as
soon as upstream releases new versions, which is quite often.
I doubt the KDE developers will guarantee that the LTS version will work
with every library upgrade. It's just too much work.
>The kernel is not only critical, but also much easier to manage -
compared to something like Plasma, which depends on anything and
everything, the kernel is for most intents and purposes a
self-contained, interchangeable box.
>Userspace software is an entirely different category, and a huge DE like
Plasma makes things even harder. Someone might try to maintain it on the
AUR, but that could easily mean upwards of 50 packages that constantly
need to be tested against new versions of their dependencies.


Ok, since I'm not that experienced to build packages especially for a huge DE like Plasma, but I feel somewhat irrelevant on the above opinion.
Do you think it's problematic to offer Plasma-LTS package on Rolling-Release model of Arch?

Thanks.

I imagine that the idea of LTS packages is in conflict with what Arch aims to provide - which is a software stack that is kept up-to-date with the latest-and-greatest software available. If you want LTS kernel and LTS packages, why not just go with an LTS distro?

Now not all rolling-release distros use that same model of bleeding-edge everything. PCLinuxOS in particular keeps the base software stack fairly stable, only updating to new versions after they've been properly vetted and a good upgrade path put in place. It would certainly be conceivable for PCLinuxOS to provide LTS Plasma as the matrix of versions that they upgrade through is a lot smaller, making it easier for the distro maintainers to verify that the new versions work with the other things they provide.