sitter added a comment.
In https://phabricator.kde.org/D4667#87551, @dfaure wrote: > I was always told "plugins should not get versioned at the .so level". Not sure why exactly. Are you sure this wasn't simply about plugins not being in public library directories? I know some people don't like that. I find it hard to find a reason why adding a bunch of digits and dots would be advised against though. That being said, I don't think the proposed solution solves anything as these plugins supposedly would be loaded through `QLibrary` and so that call would need to get a version specification when loaded... I have no knowledge over Plasma's way of using the qtquickengine though, so maybe I am talking nonesense and that is already done. > The more usual solution was version numbers in .desktop files, to query for things with the right version. I guess this can be transposed to json since Qt reads the json data without really loading the .so file. Options as I see it are: - An approach I saw in (I think) grantlee is installing the plugins to tightly versioned directories (e.g. `$prefix/lib/grantlee/1.2.3/foo.so`) and then making sure that is a qlibrary search path. - Plugins loaded by a library or application could use JSON metadata to establish version compatibility. - Lastly one could probably use soversions as suggested in the diff here combined with requesting specific versions from `QLibrary`. The latter two options actually may have negative performance impact on software with many plugins since one needs to iterate all potential directories (in JSON's case even `fopen` all files). So, the subdirectory approach is, to me, the most elegant and efficient way to version plugins. Now, all that said, I think this needs some discussion by the Plasma team on the principle of it. Ultimately QML module or plugin version-locking gives you nothing. Sure, say you lock taskmanagerplugin in step with plasmashell it probably prevents crashing by loading incompatible C++ bits. **BUT** the user can still add (potentially new) applets to the shell which in turn is then broken because of the module Plasma refuses to load because of version-locking. This is similar to a problem we had with the logout screen where loading the (new) QML assets upon logout would run into new code paths that the old plasmashell binary cannot handle and so nothing is rendered. To put it bluntly: any application that lazy-loads anything is simply broken after a "live update" with API changes. To varying degrees, sure, broken none the less. Whatever band-aid is put on top doesn't matter, the application remains partially non-functional from a user POV. The one and only way I can think of to prevent this is to have old and new versions installed side-by-side until a reboot occurs otherwise you'll have cases where you need to load new stuff (which you shouldn't) or can't load old stuff (which was replaced by new stuff). That would however require you to make distros do that (I find that unlikely to happen) and write lots of code to fully isolate the file trees. All plugins, all QML modules, all runtime assets (pictures what have you), there must not be any overlap really. You'll essentially have to make a Plasma bundle ;) Whether or not that is worth it to Plasma and to which degree, is the question we need to answer first. My 2 cents are: if the breakage does not impair in a meaningful way then the problem is unfortunate but simply the cost of doing live updates. So if the logout dialog is broken that is a big deal, if plasmashell crashes once I'll argue it doesn't matter because it would restart anyway and at that point be compatible with its own plugins again (NB: it may now be incompatible with surrounding services such as kactivitymanagerd ;)) Sorry for the rambling. This is a vast and tricky problem :) (Also see offline updates https://phabricator.kde.org/T3137 for the distribution approach of avoiding this by only conducting updates on start-up. As mentioned, bundling all of plasma would also solve this, albeit not really for distributions.) REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D4667 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: anthonyfieroni, #plasma, davidedmundson, dfaure, sitter Cc: plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
