D23800: Use ECMGenerateExportHeader to manage deprecated API better

[Friedrich W. H. Kossebau]

kossebau added a comment.


  @mpyne Thanks for the immediate review and testing
  
  In D23800#542391 <https://phabricator.kde.org/D23800#542391>, @mpyne wrote:
  
  > I encountered that excluding deprecated components from the build requires a version of x.y.z. (not just x.y) but other than that things were straightforward from a developer's perspective.
  
  
  Yes, that version precision mismatch (which I copied over from the Qt pattern for consistency) also left me a bit unhappy, as the z of x.y.z will be used with 0 value usually, as other values will/cannot make a difference. The argument I gave to myself is: deprecating API at patch-level versions does not make sense/needs support, so staying with x.y in the C++ preprocessor macros makes sense, also results in less macro implementation code. While at consumer side people would be using the hex number version value, where the z part is needed for the correct number (0xXXYYZZ vs 0xXXYY), so enforcing consumers to think in x.y.z pattern here makes sense.

REPOSITORY
  R244 KCoreAddons

BRANCH
  useECMGenerateExportHeader

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

To: kossebau, #frameworks, mpyne
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20191006/2c00f0fe/attachment.html>