minimumSize() becomes deprecated by this, the deprecation macros will
follow once the current users have been adjusted.

IMHO you should add the macros from the start, otherwise it will be only forgotten later, as there is no mechanism to remind you. And without compiler warnings all the remaining users might never learn about it.

I would expect you have prepared patches for some known users already to testdrive the new API for usefulness, so the set of remaining users (in KDE spheres) should be already small. And those not yet withzout a patch, what would be the plan to care for them? In the end it needs to compiler warnings to get other people in the game. After all API is not deprecated without a reason. Being too gentle with warnings does not help anyone in the end.

In D27989#670416, @kossebau wrote:

minimumSize() becomes deprecated by this, the deprecation macros will
follow once the current users have been adjusted.

IMHO you should add the macros from the start, otherwise it will be only forgotten later, as there is no mechanism to remind you. And without compiler warnings all the remaining users might never learn about it.

I would expect you have prepared patches for some known users already to testdrive the new API for usefulness, so the set of remaining users (in KDE spheres) should be already small. And those not yet withzout a patch, what would be the plan to care for them? In the end it needs to compiler warnings to get other people in the game. After all API is not deprecated without a reason. Being too gentle with warnings does not help anyone in the end.

There's two remaining users in everything covered by lxr, the Plasma clipboard (patch in review: https://phabricator.kde.org/D29478) and KDE PIM (which now depends on a sufficiently new KF5 version to actually do the migration). Both ways can be argued of course, I optimized for "helps me" (the warnings for things I can't change yet don't), and "migration is my problem" rather than "migration is somebody else's problem" (which is my understanding of how we are supposed to be doing KF deprecations to ease the 6 transition).

In D27989#670659, @vkrause wrote:

There's two remaining users in everything covered by lxr, the Plasma clipboard (patch in review: https://phabricator.kde.org/D29478) and KDE PIM (which now depends on a sufficiently new KF5 version to actually do the migration). Both ways can be argued of course, I optimized for "helps me" (the warnings for things I can't change yet don't), and "migration is my problem" rather than "migration is somebody else's problem" (which is my understanding of how we are supposed to be doing KF deprecations to ease the 6 transition).

For projects who cannot/do not want yet to adapt to deprecated API (e.g. because they do not fancy #if version #else #endif), they can make use of the built-in features with the deprecation system to deactivate warnings for any API which was set as deprecated initially only after a certain version:

• QT_DEPRECATED_WARNINGS_SINCE (as in, show warnings for API deprecated at least since or already in older versions)
• KF_DEPRECATED_WARNINGS_SINCE (same as above, KF_ being the group default, with KFOO_ allowing to fine-tune per module)

Both are by default set to the number of the current version (so all warnings are shown), but if using QT_DISABLE_DEPRECATED_BEFORE or KF_DISABLE_DEPRECATED_BEFORE_AND_AT (& KFOO_DISABLE_DEPRECATED_BEFORE_AND_AT) those are defaulting instead to the version given in those macro, so automatically disabling any warnings for API deprecated in newer versions. One has to actively overwrite that to see warnings again (like e..g done for KF modules gloibally in https://phabricator.kde.org/source/extra-cmake-modules/browse/master/kde-modules/KDEFrameworkCompilerSettings.cmake$68

	add_definitions(
	    -DQT_DEPRECATED_WARNINGS_SINCE=0x060000
	    -DKF_DEPRECATED_WARNINGS_SINCE=0x060000
	)

So the idea here is to allow to disable warnings for API deprecations one does not want to care about (yet). So unwanted noise should be design not be a reason here to delay adding the compiler warning macro and the compiler visibility wrapper. Note: Qt is lacking a bit here and there, some deprecations are not properly tagged to support that. KF instead shines there :)

For being silent about the warnings while still doing patches all yourself: while of course it is nice/recommended to help all KDE projects to adapt to some new API by the persons who introduced it, it also is good to get some real world feedback by having people with other mindsets who try to make use of the new API, and who thus might discover issues with the new API or its documentation. And some people are just fine to help out for their own projects to jump to latest best API as well, so they would be happy to learn about as early as possible by having the compiler points things out.

See e.g. how KRun is deprecated currently. Are people upset about the approach? I do not think so. Because they see David going around and helping with the ports. And they see how the new async API is better.

So, no harm here in having the compiler from day one inform interested developers about the deprecation. IMHO, but also covered by what is done elsewhere :) Actually, it is part of the design with the control about compiler warnings by version.