https://invent.kde.org/frameworks/ki18n/-/merge_requests/41#note_354970 - alternatives approaches to doing this (branching, local-only changes, doing nothing) are all considered worse, so agreement is to integrate these changes
https://invent.kde.org/frameworks/ki18n/-/merge_requests/41#note_355693 - using version-less targets partially runs the risk of using them wrongly - in theory creating a less impactfull test for leaking version-less targets would be possible, when having that we could safely use version-less targets e.g. for unit tests - version-less functions are separately controlled and are fine internally, but cannot be used in public CMake modules either for the same reason as version-less targets KF6 rename for libraries, soversion and CMake config files prior to branching - too ugly and too much effort for now, so wait with that until branching - this is a kf6 developer only setup for now anyway, not meant for use/ publication, etc https://phabricator.kde.org/T13157 - we need to get stricter in making sure deprecations in KF are followed up by a full port of all of KF, ideally within the same KF release - breakage would likely show up in downstream repos - look into incrementally phasing in Qt6 builds for this - for Qt5 no-deprecation build the occasional local run is probably sufficient on top of that then https://phabricator.kde.org/T12183 - KService as platform abstraction vs. KService as the Unix backend for a new abstraction? - we are mostly using KService for applications nowadays ("KApplication"?) - this would be a new class that can be phased in now, unlike a KService inheritance change or the KService::Ptr removal - wouldn't work that nicely for other classes returning KService::Ptrs atm - "KApplicationEntry", "KApplicationEntryTrader" might be the better names without the historical baggage
signature.asc
Description: This is a digitally signed message part.