On Sun, Apr 4, 2021 at 8:58 AM David Faure <fa...@kde.org> wrote: > On samedi 3 avril 2021 22:42:36 CEST Ben Cooksley wrote: > > 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 :) > > Very good point. Well, there's no time like the present :) > > Packagers agreed, 5.81 RC1 is tagged, so we're all set for bumping the > dependencies. Can you deactivate the Qt 5.14 CI jobs and let me know when > I > can go ahead? >
Perfect :) The DSL Job is running currently - once it completes you can proceed. https://build.kde.org/job/Administration/job/DSL%20Job%20Seed/619/ > > Can you also confirm that all CI systems support C++17 (gcc >= 8, clang >= > 6, > or MSVC >= 2017) and CMake >= 3.16 ? > I assume so, but it doesn't hurt to make sure :) > Per https://build.kde.org/job/Frameworks/job/kcoreaddons/job/kf5-qt5%20WindowsMSVCQt5.15/138/consoleText we are running MSVC 19.24.28315.0, which appears to correspond to Visual Studio 2019 Update 4 (patch level 3). Per https://build.kde.org/job/Frameworks/job/kcoreaddons/job/kf5-qt5%20SUSEQt5.15/214/consoleText we are using GNU GCC 10.2.1 And lucky last, per https://build.kde.org/job/Frameworks/job/kcoreaddons/job/kf5-qt5%20FreeBSDQt5.15/199/consoleText we are running Clang 10.0.1 That should be more than sufficient on the compiler side i'd imagine :) With regards to CMake: Per https://build.kde.org/job/Administration/job/Docker%20Generate%20SUSEQt5.15%20Image/20/consoleText we are running CMake 3.19 On the Windows builders: C:\Craft\CI-Qt515\windows-msvc2019_64-cl-debug>dev-utils\bin\cmake.exe --version cmake version 3.17.3 And on the FreeBSD side: root@FreeBSDBuilderKappa:~ # cmake --version cmake version 3.18.4 That should also meet those requirements quite nicely. Cheers, Ben > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > > > >
