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

[Friedrich W. H. Kossebau]

Am Samstag, 5. Juni 2021, 22:39:15 CEST schrieb 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.

Using BUILD_DEPRECATED_SINCE with what will become the KF6 Beta version (i.e. 
the version where something will disappear in preparation for KF6) should be 
possible as well. The current way of testing that no hidden dependency by 
usages of deprecated-with-already-present-replacement API still exists, by 
building all KF libraries with DISABLE_DEPRECATED_BEFORE_AND_AT=CURRENT (or 
explicit version) should not be affected by this, as after all the macro 
should yield true for bigger versions.

And the version-controlled deprecation warning macros could also be used with 
that BETA version (though we should then adapt any current usages of 
KF_DEPRECATED_WARNINGS_SINCE to not use 0x060000, but the respective KF6 Beta 
version, to silence warnings for the stuff only deprecated without parallel 
replacement and replaced/dropped for the KF5 beta.
Think e.g. as negative exapmple for what to avoid the useless warnings for 
QNetworkConfigurationManager, where we cannot do anything about while using 
Qt5 and have to do that extra work to tell the compiler to not warn for that 
class on our side.

E.g. by the (broken) example I linked before:

#if KPARTS_VERSION <= QT_VERSION_CHECK(5, 900, 0) # the 900 is broken
#include <KMimeTypeTrader>
#include <KPluginInfo>
#include <QMimeDatabase>
#include <QMimeType>
#endif

could instead be

#if KPARTS_BUILD_DEPRECATED_SINCE(5, 190) # or whatever if KF6 Beta
#include <KMimeTypeTrader>
#include <KPluginInfo>
#include <QMimeDatabase>
#include <QMimeType>
#endif

On the other hand the term DEPRECATED could be confusing here, as nothing is 
really deprecated in the traditional sense., where something is tagged to be 
removed either because being unused or in favour of another now available 
approach. So this could be considered an abuse of those macros rather, and 
where things are already complex now they might get even more complex by that 
additional meaning.

The BUILD_DEPRECATED_SINCE are there for being able to configure a build with 
or without, with a filter level by version even. Will that be needed for 
things which get fully replaced? I.e. will there be a transition time where 
both old & new are available? If not, I would make this rather a simple hard 
condition against the foreseen version where something will be replaced.

Also, if X gets replaced by Y, that X is right now also used by other things 
often in the same module, so being able to completely build without X might 
not be doable. So the macro usage cannot even be tested properly. And things 
will only be found out when actually replacing X by Y (and Y might only be 
created in the process), so any wrapping beforehand does not really prepare 
anything for someone?

Is there an example where things could be demoed/tested/experimented with?

Cheers
Friedrich