Deprecation wrappers for pre-KF6 time (was: Re: KF6 meeting notes 2021-06-05)
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)
Re: Deprecation wrappers for pre-KF6 time (was: Re: KF6 meeting notes 2021-06-05)
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)
Re: Deprecation wrappers for pre-KF6 time (was: Re: KF6 meeting notes 2021-06-05)
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 0x06, 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 #include #include #include #endif could instead be #if KPARTS_BUILD_DEPRECATED_SINCE(5, 190) # or whatever if KF6 Beta #include #include #include #include #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
Aw: Re: Deprecation wrappers for pre-KF6 time (was: Re: KF6 meeting notes 2021-06-05)
In KService (KPluginInfo) the BUILD macro variant is used for non-virtual methods, because it is used in public API of other frameworks. Though that does not seem to be used consistently. A good argument against using the BUILD variant in the header is that consumers/devs are not at all able to test the build when excluding deprecated API completely. My primary concern is that we need to keep using the classes/method, because of compatibility, like KServiceTypeTrader they should all have a viable alternative. But this means that in large parts of frameworks and plasma we can not utilize the macros that much. PS: Forgot about this thread and had this mail lying around as a draft for quite some time. Regards Alex Gesendet: Sonntag, 06. Juni 2021 um 00:46 Uhr Von: "Friedrich W. H. Kossebau" An: kde-frameworks-devel@kde.org Betreff: Re: Deprecation wrappers for pre-KF6 time (was: Re: KF6 meeting notes 2021-06-05) 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 0x06, 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 #include #include #include #endif could instead be #if KPARTS_BUILD_DEPRECATED_SINCE(5, 190) # or whatever if KF6 Beta #include #include #include #include #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
