Re: RFC: Switching to min Qt version 5.14 for KF on December 14th
El divendres, 18 de desembre de 2020, a les 18:51:32 CET, Albert Astals Cid va escriure: > El divendres, 18 de desembre de 2020, a les 6:44:41 CET, Friedrich W. H. > Kossebau va escriure: > > Am Donnerstag, 17. Dezember 2020, 21:06:23 CET schrieb David Faure: > > > In general I might have asked for a more conservative approach; but > > > currently anything we do to help with preparing the Qt 6 migration is a > > > good thing, and having one less Qt version to support helps with that. > > > > > > So, in those exceptional circumstances, I'm in favour, go for it. > > > > Okay :) And it are those exceptional circumstances also which made me push > > for > > the bump here, otherwise I would have rather tried to have us get Qt 5.13 > > back > > onto KDE CI. > > > > Albert, commit data tells me did the last bump. Could you go and do the > > bump > > to Qt 5.14 as well now, given you seem to have some setup for that? > > Running now. > > For reference: > https://invent.kde.org/sysadmin/release-tools/-/blob/frameworks/5.0/increase_qt_version.sh I've done ifdefs cleanups in all the repos that had version checks against < 5.14 and one or two build fix commits. Please check your favorite framework that i did not any mistake. Cheers, Albert > > Cheers, > Albert > > >
Re: RFC: Switching to min Qt version 5.14 for KF on December 14th
El divendres, 18 de desembre de 2020, a les 6:44:41 CET, Friedrich W. H. Kossebau va escriure: > Am Donnerstag, 17. Dezember 2020, 21:06:23 CET schrieb David Faure: > > In general I might have asked for a more conservative approach; but > > currently anything we do to help with preparing the Qt 6 migration is a > > good thing, and having one less Qt version to support helps with that. > > > > So, in those exceptional circumstances, I'm in favour, go for it. > > Okay :) And it are those exceptional circumstances also which made me push > for > the bump here, otherwise I would have rather tried to have us get Qt 5.13 > back > onto KDE CI. > > Albert, commit data tells me did the last bump. Could you go and do the bump > to Qt 5.14 as well now, given you seem to have some setup for that? Running now. For reference: https://invent.kde.org/sysadmin/release-tools/-/blob/frameworks/5.0/increase_qt_version.sh Cheers, Albert
Re: RFC: Switching to min Qt version 5.14 for KF on December 14th
Am Freitag, 18. Dezember 2020, 00:31:45 CET schrieb Albert Astals Cid: > El dijous, 17 de desembre de 2020, a les 21:16:57 CET, Ahmad Samir va escriure: > > On 17/12/2020 22:06, David Faure wrote: > > [...] > > > > > Right. That's a reason to fix something indeed, but there are still two > > > ways to fix that, if it was the only reason : either raise min req to > > > Qt 5.14, or ask for a Qt 5.13 CI. > > > > Ben said on IRC: > > "I used 5.14 as a practical matter as 5.13 is essentially unavailable" > > I'm fine going to 5.14, but saying that 5.13 is unavailable is just not the > truth. Guess it is a matter of defining "available" :) AFAIK Qt 5.13 was not available just by the change of a data point in a table. It would have needed people investing their resources into scratching that itch to create respective custom packages for at least some of the CI- supported operating systems. As well as potentially any other 3rd-party libraries/tools using Qt API that was built/packaged against newer Qt. Cheers Friedrich
Re: RFC: Switching to min Qt version 5.14 for KF on December 14th
Am Donnerstag, 17. Dezember 2020, 21:06:23 CET schrieb David Faure: > In general I might have asked for a more conservative approach; but > currently anything we do to help with preparing the Qt 6 migration is a > good thing, and having one less Qt version to support helps with that. > > So, in those exceptional circumstances, I'm in favour, go for it. Okay :) And it are those exceptional circumstances also which made me push for the bump here, otherwise I would have rather tried to have us get Qt 5.13 back onto KDE CI. Albert, commit data tells me did the last bump. Could you go and do the bump to Qt 5.14 as well now, given you seem to have some setup for that? I already adapted the respective policy like this now, based on the discussion (please fix any issues directly on the page, linked below): " With Qt6 this changes a little bit again. We interpolate "as if" more Qt 5 versions would be released: * Qt 5.13 will be the minimum required version 6 months after Qt 5.15, i.e. on 26 Nov 2020, * Qt 5.14 would be the minimum required version 12 months after Qt 5.15, i.e. on 26 May 2021. With no-one known to stick with Qt 5.13 at the time, the date was moved to earlier mid-December 2020 (see discussion) * Qt 5.15 LTS will be the minimum required version 18 months after its release, i.e. on 26 Nov 2021 The bumping of the minimum required version in the code is done at the begin of the release cycle of the next KF version affected, right after the release of the previous one. " * https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements Going to Qt 5.14 also means a bump in supported compilers, see https://doc.qt.io/archives/qt-5.13/supported-platforms.html vs. https://doc.qt.io/qt-5.14/supported-platforms.html So at least GCC 4.8 -> GCC 5, MSVC 2015 as before. Can anyone tell what the supported clang version of Qt 5.14 is? Volker, leaving the stage now for you and the considerations to update the plan for when Qt 5.15 should become the minimum dependency :) Cheers Friedrich
Re: RFC: Switching to min Qt version 5.14 for KF on December 14th
El dijous, 17 de desembre de 2020, a les 21:16:57 CET, Ahmad Samir va escriure: > On 17/12/2020 22:06, David Faure wrote: > [...] > > > > Right. That's a reason to fix something indeed, but there are still two ways > > to fix that, if it was the only reason : either raise min req to Qt 5.14, or > > ask for a Qt 5.13 CI. > > > > Ben said on IRC: > "I used 5.14 as a practical matter as 5.13 is essentially unavailable" I'm fine going to 5.14, but saying that 5.13 is unavailable is just not the truth. Cheers, Albert > > That's why team jumped to 5.14 directly, don't know the details however. > > [...] > >
Re: RFC: Switching to min Qt version 5.14 for KF on December 14th
On 17/12/2020 22:06, David Faure wrote: [...] Right. That's a reason to fix something indeed, but there are still two ways to fix that, if it was the only reason : either raise min req to Qt 5.14, or ask for a Qt 5.13 CI. Ben said on IRC: "I used 5.14 as a practical matter as 5.13 is essentially unavailable" That's why team jumped to 5.14 directly, don't know the details however. [...] -- Ahmad Samir
Re: RFC: Switching to min Qt version 5.14 for KF on December 14th
On jeudi 17 décembre 2020 00:20:41 CET Friedrich W. H. Kossebau wrote: > Hi, > > Am Samstag, 12. Dezember 2020, 22:25:32 CET schrieb David Faure: > > Just a data point on this discussion. Every time we raise the min Qt > > version, we make life easier for KDE developers, and harder for others who > > might be thinking of integrating a framework into their project. > > > > Just today I tried using a KF5 library to extend a single plugin in an > > existing webserver (which I don't control, and which is mostly written in > > python) [1]. That server is entirely set up with a docker environment on > > top of... debian buster, which has Qt 5.11.3. > > Fail. > > I'm going to have to apply a patch to the KF5 library as part of the > > Dockerfile, to port it back to Qt 5.11. No way I can convince them to > > change the base distribution, all I'll get as a reply is to port away > > from QtCore. > > > > Obviously the 5.11 ship has sailed by now, and I know we can't support old > > versions forever, but this kind of experience makes me very wary of > > raising > > requirements too fast. > > I am reading an objection to the proposed bump in these words, am I correct > in doing that? Objection is a strong word. I am not blocking the proposed bump, I am merely realizing that the balance between contributor convenience and user-convenience (where the user is a developer) is difficult to achieve, after this (anecdotal indeed) evidence. (And yes I needed something very recent, but it wasn't actually a framework, it was another Qt/KDE library, KOpeningHours. I thought it was still illustrative of what one might encounter when trying to use a KDE framework outside its usual box of "the rest of the KDE software".) > Though please those who want to support Qt 5.13 for some more time, consider > adding support for KDE CI then. It leaves a bad feeling in my stomach that > KF 5.77+ seems effectively for Qt 5.13 with a sticker "Good Luck!" right > now. I fear that lowers the image with (potential) KF consumers, it does at > least with me for other projects. > I (and possibly many other KF contributors) have no way to test against Qt > 5.13, so might introduce regressions/break things in the future, which feels > bad :/ Right. That's a reason to fix something indeed, but there are still two ways to fix that, if it was the only reason : either raise min req to Qt 5.14, or ask for a Qt 5.13 CI. In general I might have asked for a more conservative approach; but currently anything we do to help with preparing the Qt 6 migration is a good thing, and having one less Qt version to support helps with that. So, in those exceptional circumstances, I'm in favour, go for it. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: RFC: Switching to min Qt version 5.14 for KF on December 14th
On Thu, Dec 17, 2020 at 12:21 AM Friedrich W. H. Kossebau wrote: > > Though please those who want to support Qt 5.13 for some more time, consider > adding support for KDE CI then. > Right, that Qt 5.13 ship has sailed with the recent CI purge by Ben to clean up the old 5.13 builders. If we want to keep supporting it, maybe that ship should be recalled to port... Regards, - Johan
Re: RFC: Switching to min Qt version 5.14 for KF on December 14th
Hi, Am Samstag, 12. Dezember 2020, 22:25:32 CET schrieb David Faure: > Just a data point on this discussion. Every time we raise the min Qt > version, we make life easier for KDE developers, and harder for others who > might be thinking of integrating a framework into their project. > > Just today I tried using a KF5 library to extend a single plugin in an > existing webserver (which I don't control, and which is mostly written in > python) [1]. That server is entirely set up with a docker environment on top > of... debian buster, which has Qt 5.11.3. > Fail. > I'm going to have to apply a patch to the KF5 library as part of the > Dockerfile, to port it back to Qt 5.11. No way I can convince them to change > the base distribution, all I'll get as a reply is to port away from QtCore. > > Obviously the 5.11 ship has sailed by now, and I know we can't support old > versions forever, but this kind of experience makes me very wary of raising > requirements too fast. I am reading an objection to the proposed bump in these words, am I correct in doing that? Given you being KF release worker/manager and all your merits with KF, and also given no-one else so far has commented on this. I would accept that then and drop my request to adapt the current Qt compatibility road map. I tested the waters at least. Though please those who want to support Qt 5.13 for some more time, consider adding support for KDE CI then. It leaves a bad feeling in my stomach that KF 5.77+ seems effectively for Qt 5.13 with a sticker "Good Luck!" right now. I fear that lowers the image with (potential) KF consumers, it does at least with me for other projects. I (and possibly many other KF contributors) have no way to test against Qt 5.13, so might introduce regressions/break things in the future, which feels bad :/ Cheers Friedrich
Re: RFC: Switching to min Qt version 5.14 for KF on December 14th
Am Samstag, 12. Dezember 2020, 22:25:32 CET schrieb David Faure: > Just a data point on this discussion. Every time we raise the min Qt > version, we make life easier for KDE developers, and harder for others who > might be thinking of integrating a framework into their project. > > Just today I tried using a KF5 library to extend a single plugin in an > existing webserver (which I don't control, and which is mostly written in > python) [1]. That server is entirely set up with a docker environment on top > of... debian buster, which has Qt 5.11.3. > Fail. > I'm going to have to apply a patch to the KF5 library as part of the > Dockerfile, to port it back to Qt 5.11. No way I can convince them to change > the base distribution, all I'll get as a reply is to port away from QtCore. The other option is to use not just the latest KF version, but some older one which gets along with what is available. Like KF 5.65, which seems the last one that had Qt 5.11 as min dep. Or simply the KF which is available for Buster (which seem 5.54?). If that project is fine using old (now unmaintained by upstream) versions of other software, it should also be fine with using old versions of KF IMHO. Or did you need to use some feature only available in latest KF, with no option to work around and do some substitute? I am not sure that trying to be better than the rest of the stack pays back, Even more given the limited human resources we have. Just see how slowly the KF6 board moves forward. So I think the very data point presented here is an exotic one. And rather recommends to do some bugfix-only branches at points in time when minimum dependency is raised, along versions which bigger LTS distributions rely on and trying to get downstream to help with maintaining those branches. Cheers Friedrich
Re: RFC: Switching to min Qt version 5.14 for KF on December 14th
Just a data point on this discussion. Every time we raise the min Qt version, we make life easier for KDE developers, and harder for others who might be thinking of integrating a framework into their project. Just today I tried using a KF5 library to extend a single plugin in an existing webserver (which I don't control, and which is mostly written in python) [1]. That server is entirely set up with a docker environment on top of... debian buster, which has Qt 5.11.3. Fail. I'm going to have to apply a patch to the KF5 library as part of the Dockerfile, to port it back to Qt 5.11. No way I can convince them to change the base distribution, all I'll get as a reply is to port away from QtCore. Obviously the 5.11 ship has sailed by now, and I know we can't support old versions forever, but this kind of experience makes me very wary of raising requirements too fast. [1] https://github.com/osm-fr/osmose-backend/issues/555 for the curious PS: I agree with moving the dates for bumping the min req to just after a KF5 release, this makes complete sense, feel free to make that adjustment. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: RFC: Switching to min Qt version 5.14 for KF on December 14th
No time left to cut the reply short right now, please bear with me... Am Montag, 7. Dezember 2020, 16:34:16 CET schrieb Volker Krause: > On Sonntag, 6. Dezember 2020 14:20:47 CET Friedrich W. H. Kossebau wrote: > > you might have seen I asked* whether anyone knows a real world requirement > > to stick with Qt 5.13 as new current minimum required Qt version for > > current KF releases. So far no-one had to report a reason to support Qt >= > > 5.13 instead of only Qt >= 5.14 now. > > * E.g. > > https://mail.kde.org/pipermail/distributions/2020-December/000894.html > > > > So hereby I propose to switch for KF 5.78 to Qt 5.14 as minimum version, > > and change the KF dependencies policy text* to this: > > * https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements > > > > " > > With Qt6 this changes a little bit again. We interpolate "as if" more Qt 5 > > versions would be released. Then adapt to actual real world usage of a > > given Qt version: > > * Qt 5.13 will be the minimum required version 6 months after Qt 5.15, > > i.e. > > on 26 Nov 2020 > > * Qt 5.14 would be the minimum required version 12 months after Qt 5.15, > > i.e. on 26 May 2021. With no-one known to stick with Qt 5.13, the date is > > moved to earlier mid-December 2020. > > * Qt 5.15 LTS will be the minimum required version 18 months after its > > release, i.e. on 26 Nov 2021 > > " > > Thanks! I'm generally in favor of an accelerated path to Qt 5.15 as the > minimum dependency in the light of the upcoming Qt 6 transition. The > proposed approach only addresses half of the problem though, we'll end up > with the same discussion in a few month again I fear. Would it therefore > make sense to cover this as well now, so people can plan ahead? Revisiting the date of going to Qt 5.15 as min. dependency now and then to align to the real world makes sense to me. Ideally in a separate thread though, please :) As IMHO the decisions are related, but would not depend on each other (other than 5.14 < 5.15). That discussion might also want to consider how much we are able to set the date and have distributions follow us, or how much we need to adjust to the world they create and in which the KF contributors and consumers live. BTW, IMHO we should also bump the min version at the begin of the KF development cycle, for the usual reasons, not just on the very dates, which have been close to tagging/branching in the KF schedules. We would rather use those dates as needles, and then bump at the begin of the cycle for the first version released after the needle. (at least I expect KF contributors to not also only after that date being able to use the newer minimum Qt version). (the current Qt 5.14 proposal's date December 14th is derived from the timeout of the RFC, otherwise I would have proposed the bump execution to happen around version bump time, i.e. once the previous release happened). > One thing I haven't really seen addressed yet is Krita's concerns about > newer Qt versions, how do we want to handle that? Also no idea. My hope would be that in the assumed non-Qt-company patch collection the FLOSS world will create for Qt 5.15 (given there will be no further official Qt 5.15 releases, or where are we now?) someone also manages to do a fix for the QMdi on Windows regressions that popped up in Qt 5.13 (if I got the issue correctly). So Krita could use Qt 5.15 FLOSS fork with Windows and passed that hurdle. So far my bet on others resolving the issue outside KF spheres. >From KF side we already screwed Krita with KF 5.77 now here. Going back to Qt 5.12 as minimum dep for future KF versions... as much as I cheer Krita for the incredible awesome project it is, that would be a big price to pay by everyone else. Given Krita had forked some non-tier1 KF modules (for reasons I understand, and their product success confirms the decision) it also makes it harder for me to argue to have everyone sacrifice in the KF modules just for them by sticking to Qt 5.12 as min dep. For now Krita is stuck with KF 5.76 as minimum KF version then for the Windows builds, and would need to backport patches for any important bug fixes. Given that current master has MIN_QT_VERSION 5.9.0 and MIN_FRAMEWORKS_VERSION 5.44.0, building with not the latest KF modules on Windows might not be such a bummer, and perhaps those limits are not raised near KF 5.77 a lot until Krita considers Qt6 anyway? (And did Wolthera explore the feasibility of Godot as UI toolkit as another approach to the problem? ;) ) But that is my uninformed view from the outside, Boud & fellows have to fill in here with their future plans and needs/desires/ideas. Cheers Friedrich
Re: RFC: Switching to min Qt version 5.14 for KF on December 14th
On Sun Dec 06, 2020 at 08:32:36PM +0100, Adriaan de Groot wrote: > On Sunday, 6 December 2020 18:05:19 CET David Faure wrote: > > On dimanche 6 décembre 2020 17:39:38 CET Albert Astals Cid wrote: > > > * MidnightBSD > > > * openBSD > > > > > > The BSDs are a bit more unfortunate. > > > > Thanks for the information, Albert. > > > > Apparently this means bumping the requirement to Qt 5.14 would break > > OpenBSD. Will this Qt bump happen before or after the 5.77 release? Anyway, this is okay for OpenBSD. I'm working on a Qt 5.15.1 update (qt5-webengine makes me insane). > > > > How can we reach OpenBSD KDE people? > > CC'ing kde-free...@kde.org, I know it's not the same, but maybe you guys > > know? ;) I am the maintainer for KDE/Qt5+ on OpenBSD. (rsadow...@openbsd.org) so you can reach me directly. Yes there is a mailing list "openbsd-...@googlegroups.com". This will be shut down this year I see no point in maintaining this list. > > Rafael Sadowski , ping them on invent or on phab (or in the CC of this > message > :) ). Adriaan, thanks for the ping. > > [ade]
Re: RFC: Switching to min Qt version 5.14 for KF on December 14th
On Sonntag, 6. Dezember 2020 14:20:47 CET Friedrich W. H. Kossebau wrote: > you might have seen I asked* whether anyone knows a real world requirement > to stick with Qt 5.13 as new current minimum required Qt version for > current KF releases. So far no-one had to report a reason to support Qt >= > 5.13 instead of only Qt >= 5.14 now. > * E.g. > https://mail.kde.org/pipermail/distributions/2020-December/000894.html > > So hereby I propose to switch for KF 5.78 to Qt 5.14 as minimum version, and > change the KF dependencies policy text* to this: > * https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements > > " > With Qt6 this changes a little bit again. We interpolate "as if" more Qt 5 > versions would be released. Then adapt to actual real world usage of a given > Qt version: > * Qt 5.13 will be the minimum required version 6 months after Qt 5.15, i.e. > on 26 Nov 2020 > * Qt 5.14 would be the minimum required version 12 months after Qt 5.15, > i.e. on 26 May 2021. With no-one known to stick with Qt 5.13, the date is > moved to earlier mid-December 2020. > * Qt 5.15 LTS will be the minimum required version 18 months after its > release, i.e. on 26 Nov 2021 > " Thanks! I'm generally in favor of an accelerated path to Qt 5.15 as the minimum dependency in the light of the upcoming Qt 6 transition. The proposed approach only addresses half of the problem though, we'll end up with the same discussion in a few month again I fear. Would it therefore make sense to cover this as well now, so people can plan ahead? For example: > With Qt6 this changes a little bit again. We interpolate "as if" more Qt 5 > versions would be released on a slightly accelerated schedule to match the > expected convergence towards the final Qt5 release: > * Qt 5.13 will be the minimum required version 6 months after Qt 5.15, i.e. > on 26 Nov 2020 > * Qt 5.14 would be the minimum required version 7 months after Qt 5.15, > i.e. on 26 Dec 2020. > * Qt 5.15 LTS will be the minimum required version 12 months after its > release, i.e. on 26 May 2021 (I'm not tied to any specific date in there, but you get the idea) One thing I haven't really seen addressed yet is Krita's concerns about newer Qt versions, how do we want to handle that? Regards, Volker
Re: RFC: Switching to min Qt version 5.14 for KF on December 14th
Hi Rafael, thanks for your quick reply. Am Montag, 7. Dezember 2020, 06:48:44 CET schrieb Rafael Sadowski: > On Sun Dec 06, 2020 at 08:32:36PM +0100, Adriaan de Groot wrote: > > On Sunday, 6 December 2020 18:05:19 CET David Faure wrote: > > > On dimanche 6 décembre 2020 17:39:38 CET Albert Astals Cid wrote: > > > > * MidnightBSD > > > > * openBSD > > > > > > > > The BSDs are a bit more unfortunate. > > > > > > Thanks for the information, Albert. > > > > > > Apparently this means bumping the requirement to Qt 5.14 would break > > > OpenBSD. > > Will this Qt bump happen before or after the 5.77 release? After, the bump to Qt 5.14 is currently proposed to happen Mid-December, so would be seen for release consumers first with released KF 5.78 in January 2021. For KF 5.77 another bump has just happened to Qt 5.13 (was Qt 5.12 before) as per dependency plan updated earlier this year*. Which then triggered this discussion whether with what we now see being used around us we should perhaps simplify our life (as e.g. there are lots of "#if Qt < 5.14 #else #endif" in the code) and go already to Qt 5.14 now. *https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements > Anyway, this is okay for OpenBSD. I'm working on a Qt > 5.15.1 update (qt5-webengine makes me insane). Very good (and all the best to recover once done ;) ) BTW, please consider subscribing to our special-purpose mailinglist: https://mail.kde.org/mailman/listinfo/distributions where such things are discussed with the big consumers of what is released by KDE. It is a low volume mailinglist, so should not be a big price to pay for being in good loop with upstream as well as your related packaging fellows. FTR, the email asking about this topic there is https://mail.kde.org/pipermail/distributions/2020-December/000894.html Cheers Friedrich
Re: RFC: Switching to min Qt version 5.14 for KF on December 14th
Hi, Le 06/12/2020 à 18:05, David Faure a écrit : On dimanche 6 décembre 2020 17:39:38 CET Albert Astals Cid wrote: * MidnightBSD * openBSD The BSDs are a bit more unfortunate. Thanks for the information, Albert. Apparently this means bumping the requirement to Qt 5.14 would break OpenBSD. How can we reach OpenBSD KDE people? CC'ing kde-free...@kde.org, I know it's not the same, but maybe you guys know? ;) For OpenBSD It's (mainly) Rafael Sadowski aka sizeofvoid: sadowski at openbsd.org Regards. Loïc
Re: RFC: Switching to min Qt version 5.14 for KF on December 14th
On Sunday, 6 December 2020 18:05:19 CET David Faure wrote: > On dimanche 6 décembre 2020 17:39:38 CET Albert Astals Cid wrote: > > * MidnightBSD > > * openBSD > > > > The BSDs are a bit more unfortunate. > > Thanks for the information, Albert. > > Apparently this means bumping the requirement to Qt 5.14 would break > OpenBSD. > > How can we reach OpenBSD KDE people? > CC'ing kde-free...@kde.org, I know it's not the same, but maybe you guys > know? ;) Rafael Sadowski , ping them on invent or on phab (or in the CC of this message :) ). [ade] signature.asc Description: This is a digitally signed message part.
Re: RFC: Switching to min Qt version 5.14 for KF on December 14th
On Mon, Dec 7, 2020 at 6:05 AM David Faure wrote: > On dimanche 6 décembre 2020 17:39:38 CET Albert Astals Cid wrote: > > * MidnightBSD > > * openBSD > > The BSDs are a bit more unfortunate. > > Thanks for the information, Albert. > > Apparently this means bumping the requirement to Qt 5.14 would break > OpenBSD. > > How can we reach OpenBSD KDE people? > CC'ing kde-free...@kde.org, I know it's not the same, but maybe you guys > know? > ;) > The "distribution point of contacts" list that Sysadmin maintains says openbsd-...@googlegroups.com is the appropriate mailing list for KDE on OpenBSD. Cheers, Ben > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > > > >
Re: RFC: Switching to min Qt version 5.14 for KF on December 14th
On dimanche 6 décembre 2020 17:39:38 CET Albert Astals Cid wrote: > * MidnightBSD > * openBSD > The BSDs are a bit more unfortunate. Thanks for the information, Albert. Apparently this means bumping the requirement to Qt 5.14 would break OpenBSD. How can we reach OpenBSD KDE people? CC'ing kde-free...@kde.org, I know it's not the same, but maybe you guys know? ;) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: RFC: Switching to min Qt version 5.14 for KF on December 14th
El diumenge, 6 de desembre de 2020, a les 14:20:47 CET, Friedrich W. H. Kossebau va escriure: > Hi, > > you might have seen I asked* whether anyone knows a real world requirement to > stick with Qt 5.13 as new current minimum required Qt version for current KF > releases. So far no-one had to report a reason to support Qt >= 5.13 instead > of only Qt >= 5.14 now. > * E.g. https://mail.kde.org/pipermail/distributions/2020-December/000894.html > > So hereby I propose to switch for KF 5.78 to Qt 5.14 as minimum version, and > change the KF dependencies policy text* to this: > * https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements > > " > With Qt6 this changes a little bit again. We interpolate "as if" more Qt 5 > versions would be released. Then adapt to actual real world usage of a given > Qt version: > * Qt 5.13 will be the minimum required version 6 months after Qt 5.15, i.e. > on > 26 Nov 2020 > * Qt 5.14 would be the minimum required version 12 months after Qt 5.15, i.e. > on 26 May 2021. With no-one known to stick with Qt 5.13, the date is moved to > earlier mid-December 2020. > * Qt 5.15 LTS will be the minimum required version 18 months after its > release, i.e. on 26 Nov 2021 > " > > from previous > > " > With Qt6 this changes a little bit again. We interpolate "as if" more Qt 5 > versions would be released: > * Qt 5.13 will be the minimum required version 6 months after Qt 5.15, i.e. > on > 26 Nov 2020 > * Qt 5.14 will be the minimum required version 12 months after Qt 5.15, i.e. > on 26 May 2021 > * Qt 5.15 LTS will be the minimum required version 18 months after its > release, i.e. on 26 Nov 2021 > " > > I also propose that if no objections pop up until Monday, December 14th, CET > Noon, we then go that day and update the policy and have our dependency > bumping service people execute the bump to Qt 5.14. > > Your comments, please :) Personally what interests me more as a minimum Qt version is not what distributions will be shipping it, but what they have already shipped so existing people can become developers without having to compile all of Qt. Looking at https://repology.org/project/qt/badges The distros with Qt 5.13 are: * Chakra * Fedora 31 * MidnightBSD * openBSD * OpenMandriva 4.0 Both Fedora 31 and OpenMandriva 4.0 have releases with newer Qt so I guess those wanting to develop have a relatively easy path forward. Chakra seems on the "almost dead" area (Qt 5.13 for what's supposedly a rolling distribution is not a good sign) so i'm going to guess it doesn't have many users still. The BSDs are a bit more unfortunate. Not a -1 nor a -1 from my side, just wanting to provide a different perspective that's looking to the past of distributions and not to the future. Cheers, Albert > > Cheers > Friedrich > > >
