Build: Bump Qt6 from 6.6.3 to 6.7.2 (Automated PR)

[github-actions]

This automated Pull Request updates the used Qt6 version to version 6.7.2.

This PR was opened by the workflow Bump dependencies (create-prs)

CHANGELOG: Build: Updated bundled Qt6 to version 6.7.2

[pljones]

#3282 raised to make it easier to see what needs looking at.

[github-actions]

PR has been updated for version 6.7.1 by the workflow Bump dependencies (create-prs).

[pljones]

Is there a way to add some form of "back off" for want of a better term to bump-dependencies, so it's not so eager to take the very latest version? Maybe aiming for "LTS-1.patch" (long term support, version before latest LTS, but pick up latest patches for that as they may be security-related).

[softins]

I guess that would just be a case of rewriting this appropriately:

jamulus/.github/workflows/bump-dependencies.yml

Line 48 in db0724f

latest_minor="$(curl -s https://download.qt.io/official_releases/qt/ | grep -oP 'href="\K[0-9.]+(?=/")' | sort --reverse --version-sort | head -n1)";

The trick would be in deciding what the rules should be for choosing a version.

[pljones]

sort --version-sort | tail -n2 | head -n1 gets LTS-1 (and skips the unneeded reversal). Given asking for "6.7" gets us the updates from "6.7.0" to "6.7.1" here, I'd assume asking for "6.6" would keep us on latest patch to "6.6" until "6.8" (if that were an LTS) came out and then bump to latest "6.7", which is what I'd be expecting.

I don't see an easy way to get a list of tagged LTS versions... Maybe the source for Qt MaintenanceTool would reveal something.

[softins]

I don't see an easy way to get a list of tagged LTS versions... Maybe the source for Qt MaintenanceTool would reveal something.

In the Qt Github repo, the string lts only appears in tags for 5.15.x and 6.2.x:

tony@pi:~/qt5 $ git tag -l '*lts*'
v5.15.10-lts-lgpl
v5.15.11-lts-lgpl
v5.15.12-lts-lgpl
v5.15.13-lts-lgpl
v5.15.14-lts-lgpl
v5.15.3-lts-lgpl
v5.15.4-lts-lgpl
v5.15.5-lts-lgpl
v5.15.6-lts-lgpl
v5.15.7-lts-lgpl
v5.15.8-lts-lgpl
v5.15.9-lts-lgpl
v6.2.5-lts-lgpl
v6.2.6-lts-lgpl
v6.2.7-lts-lgpl
v6.2.8-lts-lgpl
lines 1-16/16 (END)

So we will have to make our own project decisions. Your suggestion of tail and head would keep us on 6.6 until 6.8 comes out, and would then move us to 6.7, if that's your intention:

$ curl -s https://download.qt.io/official_releases/qt/ | grep -oP 'href="\K[0-9.]+(?=/")'
6.7
6.6
6.5
5.15

$ curl -s https://download.qt.io/official_releases/qt/ | grep -oP 'href="\K[0-9.]+(?=/")' | sort --reverse --version-sort | head -n1
6.7

$ curl -s https://download.qt.io/official_releases/qt/ | grep -oP 'href="\K[0-9.]+(?=/")' | sort --version-sort | tail -n2 | head -n1
6.6

[ann0see]

So 6.5 is LTS (https://wiki.qt.io/Qt_version_history) but do we want to downgrade to that?

[pljones]

So 6.5 is LTS (https://wiki.qt.io/Qt_version_history) but do we want to downgrade to that?

I don't think that can be relied on

The latest version of Qt is 6.5 released on 3 April 2023

and

Revision as of 14:15, 2 January 2024 by Liang Qi (talk | contribs) (Copied directly from https://web.archive.org/web/20231201152348/https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Qt_version_history , the page was deleted in wikipedia)

It looks like someone copied it off a copy of a Wikipedia page and the original was deleted and it's not been updated (either before or) since in the Qt Wiki. The Wikipedia page would have been no more recent than 2023-12-01 (and possibly significantly older if it got locked when moved to Wikipedia:Articles_for_deletion).

[github-actions]

PR has been updated for version 6.7.2 by the workflow Bump dependencies (create-prs).

[ann0see]

(Why) don't we want to update to the latest version here for 3.11.0?

[ann0see]

@jamulussoftware/maindevelopers do we want the Qt version update in the next build or not?

[pljones]

We're still investigating how to get the version we want, whether LTS or LTS-1 but not latest stable necessarily.

(I'm running 6.7.2 on all my Linux servers and my Windows client so I've no problem, as it happens.)

We also need a strategy to get off 5.x on all platforms.