This also includes the metaDataFile method, which consequently becaomes obsolete.

I am not sure how one would go about deprecating the implicit codepath. One could of course do runtime warnings.

Another idea could be to deprecate the constructor all-together, create a fromJsonFile method and then use the constructor suggested in T15094 when one wants create KPluginMetaData object with a filename that points to a C++ plugin. Using the visibility wrappers we could add a default parameters to this constructor so that consumers don't need to change the method calls when they disable deprecated API.

In hindsight I feel like I should not have "designed" the KPluginMetaData API this way. I don't really like constructors that can fail and leave the object in an invalid state. But changing that now doesn't make any sense.

Maybe we should add a new constructor + from method that takes a flags enum with permitted "plugin file formats"?

Maybe we should add a new constructor + from method that takes a flags enum with permitted "plugin file formats"?

I don't think we need it, because with the deprecation we would only have two "plugin file formats". Considering that we rarely use the json one directly, I proposed to create a new method fromJsonFile method. (I think you had the same idea on a MR, but in a different context).

For reference: https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/175

I brought this up on the KF6 weekly and there a runtime warning for the implicit code path was seen as the best solution for deprecating the desktop files. My suggestion with the enum value for allowing empty metadata & the deprecation visibility wrappers was seen as fragile, because people often do not test the code after increasing the deprecation versions.