Revert "Temporarily lower Qt version deprecation"

[xavier2k6]

This reverts 5df4df1 introduced in PR #23499 as upstream fix for QTBUG-141994 has been publicly released.

• Upstream fixed in Qt 6.8.6 / Qt 6.10.2 / Qt 6.11.0 Beta3+

• Qt 6.10.2 Release Announcement

• Release Notes

---

Once a Qt version with a fix has been release we can raise it again.
Otherwise, I can't do a beta release on Windows.

#23499 (comment)

[Chocobo1]

Upstream fixed in Qt 6.8.6 / Qt 6.10.2 / Qt 6.11.0 Beta3+

Our INSTALL file requires Qt 6.6.0 - 6.x which mean Qt 6.6.x and 6.7.x are not covered by the upstream fix. Is it really safe to revert it back?

qBittorrent/INSTALL

Line 14 in b4b4dd7

- Qt 6.6.0 - 6.x

[xavier2k6]

• Qt 6.6.3 is last/final release of Qt 6.6.x series (non-LTS & EOL)
  https://www.qt.io/blog/qt-6.6.3-released

• Qt 6.7.3 is last/final release of Qt 6.7.x series (non-LTS & EOL)
  https://www.qt.io/blog/qt-6.7.3-released

• Qt 6.8.3 is current OSS release of Qt 6.8.x series (LTS)
  https://www.qt.io/blog/qt-6.8.3-released

• Qt 6.8.4, Qt 6.8.5, Qt 6.8.6 are only available for Commercial LTS at the moment.
  https://www.qt.io/blog/commercial-lts-qt-6.8.4-released
  https://www.qt.io/blog/commercial-lts-qt-6.8.5-released
  https://www.qt.io/blog/commercial-lts-qt-6.8.6-released

• https://endoflife.date/qt

---

• The original change was made in April 2025 via Drop support of Qt 6.5 #22599
• It only seems to have affected static based building on Windows.
• We didn't receive any issue reports since the change & was only noticed by our maintainer upon a beta release.
• More than likely most users who follow the wiki on windows will install via vcpkg & they're nearly always up-to-date, or will use our CI builds etc.

[xavier2k6]

Is it really safe to revert it back?

Other questions to ask:

• if we were to raise Qt requirement now or again in the future, will we run into the same type of issue/not know until maintainer or someone else brings it to our attention that building statically on windows will fail?

• Should we build statically in our CI on a scheduled basis/manual trigger?

(I haven't built qBittorrent manually since Qt6 introduction, rely on official releases/CI builds for testing)

[glassez]

I think @sledgehammer999 could just work around similar issues locally rather than pushing it in the codebase, given that they don't affect in most of the cases.

[Chocobo1]

Qt 6.6.3 is last/final release of Qt 6.6.x series (non-LTS & EOL)
...

It seems that the only truly safe path is defer this revert until we raise the minimum supported Qt version to 6.8. To be precise, it is Qt 6.8.6 and not 6.8.0, but I hope users will be using the latest release in the 6.8 series. This concern is related to the Qt version specified in the INSTALL file.

if we were to raise Qt requirement now or again in the future, will we run into the same type of issue/not know until maintainer or someone else brings it to our attention that building statically on windows will fail?

It is like all other reported issues. We won't know until someone reports it and then we fix afterwards.

Should we build statically in our CI on a scheduled basis/manual trigger?

IMO this issue is quite minor and static builds are too slow and require high maintenance, and therefore not worth it.

I think @sledgehammer999 could just work around similar issues locally rather than pushing it in the codebase, given that they don't affect in most of the cases.

I can see why he wants it in the codebase. It is about having no local (hidden) changes for a binary release. However, this point is moot since the release build process isn't public. BTW, I strongly support making the release build process public. Similar to what docker and flatpak are doing.

[glassez]

BTW, I strongly support making the release build process public.

We've been talking about this for years, but to no avail. @sledgehammer999 doesn't want to let it out of his hands.

[xavier2k6]

How about ammending the INSTALL file/cmakelist for OS conditionals.......

If Linux/macOS Qt 6.6.0+ & Windows = Qt 6.8.6/ Qt 6.10.2

• Qt 6.8.6 was released to Commercial LTS in December 2025, & if they follow previous OSS release like Qt 5.15.x then Qt 6.8.6 source files will be publicly available in December 2026, pre-built binaries will not be available under CI.

• Qt have different CMake requirements for OS when building from source as I've previously brought up.

[Chocobo1]

We've been talking about this for years, but to no avail. @sledgehammer999 doesn't want to let it out of his hands.

Yeah, we can setup the whole build process and let sledgehammer999 decide when to push the run button. But I'm not optimistic about it.

How about ammending the INSTALL file/cmakelist for OS conditionals.......

I suppose you can still go forward with this PR as-is without my approval if you strongly insist. Also I consider adding OS conditionals to INSTALL a bit too much. It would be OK to add it to cmake though.

[xavier2k6]

I suppose you can still go forward with this PR as-is without my approval if you strongly insist.

I don't strongly insist but perhaps other @qbittorrent/bug-handlers who haven't contributed to this proposal so far, can weigh-n & express their opinions or suggest alternatives etc.

Also I consider adding OS conditionals to INSTALL a bit too much. It would be OK to add it to cmake though.

Another thing with regards to CMake's Requirements is with the find_package option(s) for OpenSSL etc.

Added in version 3.18: Support for OpenSSL 3.0.

Our Min OpenSSL is 3.0.2, yet our min CMake is 3.16 etc.

Do we put OS conditionals or set an overall minimal (one size fits all)?

• https://cmake.org/cmake/help/latest/module/FindOpenSSL.html
• https://cmake.org/cmake/help/latest/module/FindZLIB.html
• https://cmake.org/cmake/help/latest/module/FindBoost.html