Hi,

with my KDE Android hat on this would be fine, we use Qt 5.15. For KDE's
own Windows/Mac builds I'd expect it to be similar.

What most/all not-traditional-Linux-distro users have in common is that
they are not bound to the specific Qt version decided and shipped by a
vendor and instead either build themselves or download official binaries.

The two major "distributions" that are potential frameworks users but
can't because of Qt versions (SailfishOS and Ubuntu Touch) don't ship
5.13 either, so it doesn't make the problem worse.

Cheers

Nico


On 12/1/20 1:29 PM, Jonathan Riddell wrote:
Not from KDE neon of course, we're on 5.15.  And not from the KDE
snaps build either.  But I suppose there's more than just Linux
distros to consider as we ship apps using KDE frameworks on Flatpak,
Android, Windows, even Mac to ponder too.

Jonathan


On Tue, 1 Dec 2020 at 12:14, Friedrich W. H. Kossebau
<kosse...@kde.org <mailto:kosse...@kde.org>> wrote:

    Hi,

    last week KDE Frameworks master saw a bump in the
    required/expected minimal Qt
    version to Qt 5.13, following rules once agreed and noted here:
    https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements
    <https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements>

    I would like to challenge that former decision though and propose
    to instead
    go straight to Qt 5.14 as minimum requirement now.


    QUESTION:
    Would any of the distributions have an issue with requiring Qt
    5.14 instead of
    Qt 5.13?


    From some quick checks using https://repology.org/
    <https://repology.org/> it seems that any
    distribution versions which currently use Qt 5.13 have also
    settled on some
    older KF version, so will not update to just KF 5.77 and thus be
    screwed.

    Motivation:
    * KDE CI not setup ATM to cover builds with Qt 5.13 (no build, no
    unit tests)
    * Qt 5.14 added some new API, chance to miss out when using that
    in new code
    * C++: no need to write #if QT_VERSION < QT_VERSION_CHECK(5, 14,
    0) variants
    * QML: no need to do hard-to-read generation tricks to support <
    Qt 5.14
    * Qt 5.13 went out-of-support in June
    * App bundle builders would rather use some recent Qt 5.14/5.15

    So by restraining to Qt 5.13 as minimum version IMHO we would
    make/keep life
    complicated for KF contributors without adding any value for anyone.

    With most of KDE Frameworks in my local checkout:
        grep "QT_VERSION_CHECK(5, 14, 0)"  frameworks/*/src -r
    2>/dev/null | \
            grep "QT_VERSION " | wc -l
    gives me "92", so there are quite some code variants which need
    support in
    current code.

    From the emails at least in
    https://mail.kde.org/pipermail/kde-frameworks-devel/2020-July/112712.html
    <https://mail.kde.org/pipermail/kde-frameworks-devel/2020-July/112712.html>
    I could not see a discussion whether Qt 5.13 makes
    sense at all now, seems mainly the algorithm was applied. I
    propose to match
    the result to known real world needs now. Or teach me what I have
    missed here
    :)

    Cheers
    Friedrich


Reply via email to