Should we change the way we approach minimum Qt/KF5 requirements?
Right now we "floor" the Qt5/KF5 requirements based on what popular distros deliver.
This is really only for developers' convenience, for them to be able to use repository packages without having to compile any dependency from scratch. The actual binary packaging by distributions is mostly unaffected, since:
- they traditionally rarely back-port new software versions into the released distros – and if they do, they update their dependencies, too.
- we offer AppImage anyway, and hopefully FlatPak soon.
That having said, "flooring" the version for developers' sake has many disadvantages:
- we end up with a lot of conditional blocks that intend to support old and new versions of Qt/KF5
- we are slow to update the code that has been obsoleted upstream
- since devs use older version of dependencies, not much testing is done with newer ones, which upcoming distros use, as well as binary packages (AppImage, macOS DMG, Windows MSI)
- major changes to the code may be difficult to be made backwards compatible at all, see e.g. !122 (merged)
- we are slow to take advantage of API improvements upstream, which in turn can benefit end users with features or us with simplified code and/or dev env
- not all distros provide sources for the dep packages, which make it difficult to debug and understand issues related to Qt5/KF5 code itself.
What I'd like to suggest, instead, is that we:
- default to current up-to-date KF5/Qt5
- with KF5/Qt in vcpkg, we can ask that developers use vcpkg to compile dependencies
- , or that they do that themselves
- , or that they use a docker image (that would provide a ready-made dev env with all required dependencies)
- , or that they use the bleeding edge KDE's own packaging repositories with up-to-date KF5/Qt packages. This, however, may require setting up separate dev env to avoid messing up with their daily driver machines.
Edited by Dawid Wrobel