Hi all, here are the notes from today's KF6 weekly call:
C++ 17 - can we use std::optional in public API? KPluginLoader has that need - we need to keep source compatibility with older KF5, so unconditional C++17 includes can be a problem during the remaining KF5 lifetime (but not for KF6) - should KPluginMetaData have an invalid state or only be wrapped in std::optional? we need the invalid state anyway for QVariant, so the former might be cleaner 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) - adding them now would prevent bumping the minimum version ever again - 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? Do KIO slaves still need the klauncher/kinit loading mechanism? or could that be replaced by json metadata based plugin loading as well? - is the performance benefit of kinit still relevant there? - for in-process KIO that would be needed anyway -> needs input from David F Plasma Framework plugin version check: can this be replaced by a simple namespace check? - does a detailed version check besides a check for matching version number, might not be needed anymore as the plugin API is stable - https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/268 - would allow further cleanups of plugin macros in Plasma (https:// phabricator.kde.org/T14542) -> no longer needed and can be cleaned up Co-installability: - ksendbugmail is unversioned -> rename - protocol2json -> remove in kf6 KF6 Documentation: - Porting guide: we need to collect relevant porting information for this, but we currently have no place for this yet. - can we extract that from the deprecation documentation in KF5 source code? (such as https://invent.kde.org/frameworks/kio/-/blob/master/src/widgets/ krun.h#L196) -> Carl looks into this - where should we collect porting information? -> Frederik looks into this
signature.asc
Description: This is a digitally signed message part.
