On Sun, Apr 4, 2021 at 2:18 AM David Faure <fa...@kde.org> wrote: > Here are the notes from today's meeting (thanks Luigi ) > > Feature deprecation process > ============= > - when to deprecate a feature? Deprecation signals people that they should > start porting, but on the other hand the users of a certain feature may > need > help and the new feature may require some stabilization; > - a change on a complex application (ex kmymoney) may require help from > both > the Frameworks developers and the application developers, both with their > specific knowledge > - conclusion: deprecate as soon as the replacement is proven to be > effective > in relevant use cases, and the deprecation doesn't mean the people who > worked > on the deprecation stop working on the porting of the application > > Back on https://phabricator.kde.org/T14233 (ECM and multiple Qt version) > ============= > > TODO: build a proof of concept with solution 2) (make sure > find_package(Qt) is > called explicitly before find_package(ECM)) with some real repository and > see > how it looks like. Other discussions about the general solution. See > solution > 3 added to the task right now. > > Back on https://phabricator.kde.org/T14164 (Create version-less KF cmake > targets) > =========== > > (brief summary from the sprint discussion, please check the task) > The perfect solution would be to accept both (versioned and unversioned) > targets but write the correct one in the configuration files, but such a > solution doesn't seem to be possible from the previous discussion (may > need > additional discussion with steveire, and changes in cmake) > > > Update on https://phabricator.kde.org/T13806 (KParts plugin cleanup) > =================== > > The feature is only used by Konqueror, so it can be moved to the > application > and removed from Frameworks > > Timeline for bumping dependencies? > ======================= > (Qt 5.15, C++17, CMake >= 3.16). Already agreed (by distributions). It > needs > to be done (can happen now, since tagging just happened) and be advertised > in > the proper channels (announce). Problem solved! >
If we could get a heads up when this is supposed to happen so I can decommission the Qt 5.14 CI jobs that would be appreciated. That should also avoid a flurry of failure messages to the list when those jobs inevitably fail :) > Possible point of discussions for the next KF6 meetings (so that people > are > around)? > ====================== > Possibility: Plasma-related topics; KIO-related topics. Maybe solve lower- > level first? (QTextCodec - blocked on Qt regaining support on those old > codecs, state changed). > Proposed for next week's meeting: > - KGlobalAccel (T12063) > - KPluginInfo kcmservices (T13555) > - KSelectAction (T12097) > > See you next week! > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > > > Many thanks, Ben
