Topics remaining from last week: * Raising the Qt minimum version to 5.15.2: https://mail.kde.org/pipermail/ kde-frameworks-devel/2021-July/118039.html * STL use in KF implementation: https://invent.kde.org/frameworks/kio/-/ merge_requests/484 * Friedrich's alternative ECM branching proposal: https://mail.kde.org/ pipermail/kde-frameworks-devel/2021-July/117990.html
New topics from this week: * C++17 porting documentation: https://mail.kde.org/pipermail/kde-frameworks-devel/2021-July/118146.html * https://phabricator.kde.org/T14727 5.15.2 update: * Require 5.15.2 now * Pay attention to not use the slow porting API from QStringView in hot paths during the 5 era. STL use in KF: * The use of STL in the implementation is certainly ok. * We do not want needless mass porting from Qt to STL containers though, when changing this there should be an actual reason (example: better container for the job, double-lookup prevention, etc). ECM major version/release strategy * there is a lot of Qt-independent code in there where branching isn't necessary * branching would make work easier for ECM developers, but harder for ECM consumers * for the very Qt5 specific parts (e.g. things relying on qmake or the install dir handling), we are defacto branching by splitting those files into a 5 and 6 variant, which also reduces the risk of regressions in 5 * for install dirs we probably want to reduce the shared code between those two that were introduced during splitting * for those cases we can then start from a clean slate for Qt6 * it's worth thinking about a removal strategy for deprecated stuff, e.g. dropping things deprecated for N releases for a sufficiently large N? * this is only an option for things that actually have a replacement (like new install variables) * this is not useful for e.g. old Qt versions, as those then become unbuildable in modern environments (the "Helio use-case") C++17 Porting Docs * there is actually not a whole lot * not mentioned in the thread yet: * std::auto_ptr * std::random * http://www.cplusplus2017.info/removed-features-from-c17/ * related problem: output of gperf/bison/yacc/flex/etc code generators. Static Plugins * needs to be switchable, as this can't follow BUILD_SHARED_LIBS (a dynamic interface can work both with static and dynamic plugins) * should KPlugin[Factory|MetaData] abstract plugin loading and meta data access for both static and dynamic plugins? yes! * https://phabricator.kde.org/T14314 Co-installability of System Settings * probably not required, due to Plasma also not being coinstallable? Plasma plugin versioning: * https://phabricator.kde.org/T14724 - David E says this can go
signature.asc
Description: This is a digitally signed message part.
