E-Mail von Albert Astals Cid vom Sonntag, 8. Dezember 2024, 12:12:41 MEZ: > El diumenge, 8 de desembre del 2024, a les 11:32:34 (Hora estàndard del Centre > d’Europa), Tobias Leupold va escriure: > > E-Mail von Albert Astals Cid vom Sonntag, 8. Dezember 2024, 11:19:21 MEZ: > > > El divendres, 6 de desembre del 2024, a les 13:58:01 (Hora estàndard del > > > > > > Centre d’Europa), Tobias Leupold va escriure: > > > > E-Mail von Heiko Becker vom Freitag, 6. Dezember 2024, 13:50:51 MEZ: > > > > > On Friday, 6 December 2024 12:08:46 CET, Christophe Marin wrote: > > > > > > Slightly related to this release, packagers need to know what to do > > > > with > > > > > > > > packages depending on Qt 5 and marble: > > > > > > > > > > > > - kgeotag (1.6.0 release only supports KF5/Qt5) > > > > > > - kphotoalbum (5.13 release only supports KF5/Qt5, but the > > > > > > marble dependency > > > > > > is optional) > > > > > > - kexi (no release for the past 5 years) > > > > > > > > > > Just to add some piece of information here, because one could get the > > > > > impression that Marble is a hard dependency of kexi. Actually it's > > > > > optional > > > > > as well. And while the current release searches for (Kexi)Marble, the > > > > > respective subdir is commented out (and still is in git master), so > > > > > I'd > > > > > say > > > > > it doesn't depend on marble at all the moment. > > > > > > > > > > > - kreport (no release for the past 5 years) > > > > > > > > > > It's an optional dependency there, too. > > > > > > > > > > > I'm not expecting users will notice if we drop kexi and kreport, but > > > > > > > > having > > > > > > > > > > solutions for the other ones before the 24.12 release would be nice. > > > > > > > > > > Seems we're not particular good at foreseeing such things... > > > > > Six days isn't much time, but I added Tobias in CC to hear if a > > > > > soonish > > > > > release of a Qt6-based kgeotag may be realistic. > > > > > > > > > > Regards, > > > > > Heiko > > > > > > > > PS: Maybe also important: The next KGeoTag release will be buildable > > > > both > > > > against Qt6/KF6 as well as Qt5/KF5, whereas the next KPA release will be > > > > Qt6/ KF6-only. > > > > > > Unless you really really have a reason to support both Qt5 and Qt6 (i.e. > > > > it's > > > > > a plugin or library) I would really suggest you support just one (Qt6 > > > preferably). > > > > Hi Albert, > > > > for KGeoTag, it was no big deal to keep it compatible with both Qt 5 and Qt > > 6 (not so for KPA), so I thought it wouldn't hurt for now? At least as long > > as I can still use Qt 5 on my Gentoo box or using some LTS distro VM (like > > the oldest still-maintained Ubuntu or such, the plan was to support Qt 5 > > until Ubuntu LTS is Qt-6-based if possible). > > > > Of course it would be no problem to drop Qt 5 compatibility with the next > > release, this would strip down to removing the respective parts of > > CMakeLists.txt along with that one QT_VERSION_CHECK macro call in main.cpp I > > needed. > > > > But just to understand the reasoning: Why is it bad to still support Qt 5 if > > it's possible without noteworthy effort? > > Because at the end it is a noteworthy effort. > > For each distribution packager that sees that the code compiles with both Qt, > they have to decide/investigate "which is the good/really supported one". > > For each bug you get, if it's in Qt5 and you're usually running Qt6 (or the > other way around) you have to double guess if it's a bug in the code, a bug in > Qt, the user being unclear, etc. If you can remove a variable, it's a good > thing. > > For each patch that people send, they need to make sure it compiles against 2 > Qt versions that may not be trivial for them to check. > > It makes it a bit harder for our translations since our model really only > supports one development_branch+Qt combination and you are having two (master- > KF5 and master-KF6) > > It also makes it harder for our sysadmins since like the distribution > packagers they don't know which is branch is "the good one", so they don't > know if removing the Qt5 build would be a fatal blow for the project or not. > > For each gitlab pipeline that runs, we're potentially causing more climate > change for not even a good reason (if the previous points have somewhat > convinced you). > > It deviates from our general practives, we usually only support one Qt > (partial exception being plugins and libraries) except when we are in process > of porting the app, so when i go to KGeoTag and see it builds with Qt5 and > Qt6, my immediate thinking is that Qt5 is the good one and that Qt6 support is > still being worked on. > > I really understand and support the desire for the code to build in something > old as Ubuntu LTS (We normally have that in Okular too) but in this case it > means until 2026 which may not really be feasible. > > Cheers, > Albert
Woah, okay -- I see. Thanks for the comprehensive explanation. Well, then I think a reasonable approach would be to remove the Qt 5 support with the next release. I think this will take some time anyway, and thus Marble >=24.12 will already have landed in most (non-LTS) distros, so that there's no problem. > > > > Cheers, Tobias > > > > > Cheers, > > > > > > Albert
