D29281: Deprecate defunct functions

[Alexander Lohnau]

alex added inline comments.

INLINE COMMENTS

> kossebau wrote in abstractrunner.h:154
> The text in the API dox can stay "Since 5.0".
> 
> The only crititical thing where the number of an older, already released version should not be used is the KRUNNER_ENABLE_DEPRECATED_SINCE macro. Because that reacts to KF_DISABLE_DEPRECATED_BEFORE_AND_AT (or KRUNNER_DISABLE_DEPRECATED_BEFORE_AND_AT if set). And someone using, say KF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x050000 in their projects because they checked their software and it has not used any deprecated API up to that version, and who still uses this newly deprecated API, would suddenly get no longer building software, which especially is annoying with already released code.
> 
> So: when retroactively tagging deprecated API, in the API dox text mention the correct version where actual deprecation happened, in the macros the version of the upcoming release where the deprecation macros are first existing for API users. Makes sense?

That makes sense, but I want to express that this method has been defunct  since version 5.0
so that the maintainers of existing plugins can be sure that they can savely remove the method calls.
Whats the best way to express this?

REPOSITORY
  R308 KRunner

REVISION DETAIL
  https://phabricator.kde.org/D29281

To: alex, #plasma, broulik, davidedmundson, vkrause
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200429/3b4e746b/attachment-0001.html>