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
