Deprecation wrappers for pre-KF6 time (was: Re: KF6 meeting notes 2021-06-05)

[Alexander Lohnau]

Or could we use the BUILD_DEPRECATED_SINCE variant in this case? Like we
already have to do with virtual methods.

This way one would still be able to test it when compiling the framework
without deprecations. Existing API users will still be informed about the
deprecations by the compiler warnings.

Regards
Alex

On Saturday, 5 June 2021 16:57:43 CEST Friedrich W. H. Kossebau wrote:
> Am Samstag, 5. Juni 2021, 16:29:10 CEST schrieb Volker Krause:
> > Deprecation wrappers macros:
> > - should those also be added for things that have no replacement yet, or
> > where the replacement will only become available for KF6?
> > - trader queries is one such example (https://phabricator.kde.org/T14543)
> > - so should we set the version to 6.0 for those instead? avoids leaking
> > into KF6 by accident and doesn't block the usage of those macros
> > elsewhere?
> I propose to not use 6.0.0. but some beta-like version number, e.g. 5.190.0.
> ((Beware, our use of the hexnumber version scheme 0xXXYYZZ limits the
> individual numbers in the version to the range 0..255)).
> Otherwise those macros will trigger only on release version bump time, which
> would be too late.
>
> Now the challenge is to find a good minor version number for KF6 Betas :)
> And have this properly documented, so people use the same working trigger
> version. At least one place uses QT_VERSION_CHECK(5, 900, 0) which does not
> do what we expect...
> See https://invent.kde.org/frameworks/kparts/-/blob/master/src/
> partloader.cpp#L21
> (should be fixed in the process)
>
> Cheers
> Friedrich (sadly no resources currently to help more with KF5->KF6)