Why KDE Plasma 5.12 instead of 5.14 or 5.15 ?

Hi,

just read the release announcement of Leap 15.1 and I’m surprised to read that it ships with KDE Plasma 5.12. I know there has been an update to 5.12.8 recently, but nonetheless I expected to see a newer version.

I know, I could switch to TW, which shiped e.g. kde frameworks 5.58 yesterday, but TW is too much factory.

No, I’m asking this question to learn about the reasons for keeping an old version.

I suppose it is because Leap emphasizes stability.

You might consider using Argon from HERE

That gives you bleeding edge KDE on top of a Leap base. But I see that the current Argon iso is still based on Leap 15.0, so I suggest you wait a few days and see whether a future release will be rebased on Leap 15.1.

I thought the same but that is the latest long term supported version of KDE/Plasma.

You can bring 15.1 KDE/Plasma up to date with the repo below:

http://download.opensuse.org/repositories/KDE:/Frameworks5/openSUSE_Leap_15.1/

While technicaly your advice may be OK, you certainly do not bring Leap 15.1 “up-to-date”.

As @nrickert said, Leap versions are concentrating on stability. The whole combination of software packages that make up a Leap version is tested together and thus frozen from a certain moment in time and then that combination is released. While everybody is free to replace parts of the released version with other (newer or older) packages, this is not bringing that Leap version up-to-date. It is then no longer the realeased Leap version.

You do this of course at your own decision. People here will still be willing to help you when you encounter problems, but be aware that the particular combination you have will then deviate from what the majority here has., which may infulence the ability to help in a negative sense.

Thank you!

Is there a way back, either with zypper or Yast? You see, in case it doesn’t work as expected? Without new installation of the whole OS, of course…

Is there a way back, either with zypper or Yast? You see, in case it doesn’t work as expected? Without new installation of the whole OS, of course…

That has costs me a couple of hours to switch back, because of dependencies…

As @nrickert said, Leap versions are concentrating on stability. The whole combination of software packages that make up a Leap version is tested together and thus frozen from a certain moment in time and then that combination is released. While everybody is free to replace parts of the released version with other (newer or older) packages, this is not bringing that Leap version up-to-date. It is then no longer the realeased Leap version.

This is a very valid point. While the KDE/Plasma update repo is tested this is not as extensively as Leap 15.1 itself. If having to do a re-install in the future sounds not so good, it might be best to stick with the default KDE/Plasma version. That said, for testing purposes I have up-dated a ‘clean’ install of Leap 15.1 yesterday to the latest version of KDE/Plasma and KDE applications and everything works fine. Three repos need to be added:

http://download.opensuse.org/repositories/KDE:/Frameworks5/openSUSE_Leap_15.1/

http://download.opensuse.org/repositories/KDE:/Applications/KDE_Frameworks5_openSUSE_Leap_15.1/

http://download.opensuse.org/repositories/KDE:/Qt:/5.12/openSUSE_Leap_15.1/

Thank you. I gave these three repos a priority of 97, but I failed to upgrade to them, in Yast as well as with Zypper. ‘zypper dup --allow-vendor-change’ produced 68 “problems”. In Yast, although the box in the menu “allow vendor change” is ticked, Yast asks for hundreds of manual conflict solutions, despite all of them being the same: allow vendor change…

Any hints…, --?

Use the command line:


zypper dup --from repo-name --allow-vendor-change

Replace “repo-name” with the actual name you used for that repo (or the alias also works).

You may need to do that three time for the three repos.

Actually, I just edit “/etc/zypp/zypp.conf” and set

solver.dupAllowVendorChange = true

and then it will work in Yast. But I guess that is riskier if you are not careful with your repo priorities.