@kossebau In KRunner exists static QVector<KPluginMetaData> runnerMetaDataList(const QString &parentApp = QString());. Not sure if adding a overload & deprecating the one which uses the parentApp parameter is a good solution, because it adds noise to the public API and the parameter is not used anywhere. Would be just adding a notice to the docstring instead be a good to avoid the noise?

What do you mean by noise? Yes, deprecation markup makes API less pretty and harder to read, but I would always do it properly and add compiler warnings for the old variants, to have a way to inform existing users. And relying on lxr.kde.org is not enough, KF targets external users as well (thus e.g. the LGPL) and they might do whatever crazy things. with what we provide in the API. Which should be fine IMHO, and KF should support them the same way like KDE-internal projects, making sure they are informed in time and not hit the wall hard.with KF6.
Also doing exceptions is laying the founddation for the general rule to be ignored more and more, until it is rotten and too many no longer bother to do proper deprecation, because "others also did not do it here" and "it is hard to read" etc. Ruining the whole concept. My take on it.

Besides, remember that all the deprecation markup also is used to allow testing if there are no hidden dependencies internally, so that at KF6 branching time all the wrapped code can be cut out without bad surprises.

Yeah, making it harder to read for API users and also adding an overload would cause one to basically duplicate the method.

Or putting just this one parameter in the *BUILD_DEPRECATED* guard? Then one could build KRunner without deprecations and could properly test one's code.

I would not agree having the new signature as own entry next to the old deprecated one in the API docs makes the docs harder to read. IMHO having all the undeprecated, for now future-proof API without any "but do not use that detail, will be gone" etc makes things easier to digest, no? In a perfect world doxygen would be capable to do what QDocs can, split off all the deprecated API onto a separate page, so by default one only sees undeprecated API, with api.kde.org at least of the latest version (or with QCH from packages with that of the locally installed one). But still having things on the same page it is easier to just skip those tagged with deprecated (though perhaps some CSS could be used to make the deprecated ones stand back some more)

I can only repeat myself for how good deprecation work is done IMHO:

• any deprecated API usages are reported to potential users via compiler warnings (with the option to control warnings when not yet wanted)
• any deprecated API is also documented as such in the API docs, so any new usages are prevented from the start
• any deprecated API can be checked for not being used internally by implementation of undeprecated API

Yes, with C++ sadly there is no proper built-in support and one has to do all that complicated macro dance and docs things. And sometimes duplicate some implementation because one cannot easily implement the deprecated API in terms of the new one. That sucks big times. But IMHO us having done that dance so far for all the places has bought as much progress in the end, it is an investment now which will pay back a lot one switching to KF6. And having the new API already here also available for unit tests adds to being prepared for the future, After all rather nobody repeatedly makes sure that the deprecated-implementation-excluded builds properly build and tests work, so the wrappers with BUILD sadly contain a bit of surpises with them (still sad I did not push harder to have some build variant on KDE CI, so everyone could easily track the sate, I did not expect KDE to move so slowly WRT Qt6 :( )

And sometimes duplicate some implementation because one cannot easily implement the deprecated API in terms of the new one. That sucks big times

Yeah... in this case it is also rather trivial.

I did not expect KDE to move so slowly WRT Qt6 :(

I hope you can see that me and other devs are trying to get much stuff in the KDE API cleaned up & ready for KF6 :)

I hope you can see that me and other devs are trying to get much stuff in the KDE API cleaned up & ready for KF6 :)

And am happy to see that, but I had somehow hoped we would be there in 2020 and align with Qt6 releases, to also shape their API & features by feedback ;) (compare the dates when I filed and discarded T13157)

The implicit code path in kpackage where X-KDE-ParentApp was used is deprecating, specifying it explicitly in the metadata for the appstream generation seems valid.

Plasma::PluginLoader still uses X-KDE-ParentApp to restrict some items to a specific parent app. The concept is sound, e.g. there could be a plugin thing that only makes sense with Latte that we don't want to show in regular Plasma.

X-KDE-ParentApp is an odd name, but not sure it's worth renaming just for cosmetics