Saying goodbye to Qt 5

[getchoo]

Goal

Find a good pathway for the removal of Qt 5. This should affect the least amount of users possible, while also allowing us to scale back our usage over time (and where appropriate)

Motivation

Following the release of Plasma 6 on Linux and the proliferation of Qt 6 support on all platforms, we now have very little to distribute Qt 5 builds or maintain backwards compatibility. This would bring a few benefits -- mainly streamlining development a bit more, lightening the load on downstream packagers, and simplifying our distribution. The baseline experience of the launcher would also be improved with features introduced in Qt 6 such as better support for high-DPI scaling

Specification

Before making code changes, we should scale back our distribution of Qt 5 builds. The priority here will be Linux, as that's where we have the most packages of the launcher.

A good place to start may be distributions like Fedora and NixOS, that are both featuring Plasma 6 in their upcoming releases and are quick to deprecate previous versions. Starting here would have much less of an impact on users than on Debian/Ubuntu for example, where Plasma 5/Qt 5 will still remain the default for widely used and supported versions. Over time we should help downstream packagers continue deprecations, preferably coinciding with major releases of their distribution.

For Windows and(we dropped support for Qt 5 in Windows already, oops!) MacOS, we may be able to deprecate these builds sooner (unless I'm forgetting a compatibility issue here?). Users of either operating rarely depend on or use Qt 5 tools, so breakages caused by the upgrade should be minimal. For the sake of this RFC, I propose dropping them for 9.0

Once most of these deprecations are complete and we know a vast majority of our users can have a good experience with Qt 6, #2174 should be merged. This would end upstream support for Qt 5 completely on all platforms

Drawbacks

• Support for older operating systems
  • Qt 6 (especially newer versions) have higher hardware/software requirements. Removing support for Qt 5 may have an effect on platform support in the future due to this, as we would no longer have a fallback
• Theming support on Linux
  • For distributions/users who have no upgraded to Plasma 6, this will eventually lead a to a poorer experience

Unresolved Questions

• How should we decide when "a vast majority of our users can have a good experience with Qt 6"?
  • I would personally set this at when Debian stable has Plasma 6 by default

Alternatives Considered

• Keeping Qt 5

This suggestion is unique

• I have searched the issue tracker and did not find an issue describing my suggestion, especially not one that has been rejected.

You may use the editor below to elaborate further.

Related issues here!

NixOS/nixpkgs#305556 - nixpkgs deprecation

[DioEgizio]

For the sake of this RFC, I propose dropping them for 9.0

Windows-MSVC-Legacy was already dropped in 8.0

[Earthcomputer]

Qt 6 is still broken on archlinux: #991

[DioEgizio]

arch problem, compile prismlauncher yourself with the source aur package, it's not on our side that arch broke ABI compatibility

[Scrumplex]

Or use the AppImage/Flatpak packages. -bin packages are inherently broken, and no Arch package maintainer wanted to pick up Prism Launcher into the main repos.

[DioEgizio]

To add to this, even upstream Qt thinks it's a bad idea (see https://bugreports.qt.io/browse/QTBUG-112332?focusedId=786408&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-786408). Maybe we should just deprecate the prebuilt tarball and start shipping Qt in our portable builds

[Earthcomputer]

I'm sorry but dismissing this as an "arch problem" is not very helpful. Even if a problem is not your responsibility, in the OP it's stated that you want to switch once the "vast majority" of users have a good experience with Qt6. Making sure that there is a solution to this problem is I think part of that.

[Trial97]

You can use chaotic aur if you do not want to build prism yourself: https://github.com/chaotic-aur where you have either the latest release or the git package(the nightly builds): https://pkgs.org/download/prismlauncher

[Earthcomputer]

I think simply removing the bin package from the aur (or marking it as broken) would be a sufficient solution for now.

[getchoo]

I think simply removing the bin package from the aur (...) would be a sufficient solution for now

this wouldn't be "simple", as any user at any time could revive it. there's also the chance of a malicious actor adopting the package and distributing their own binaries, which would have to be from a source besides us, as ours don't work. this is a risk i don't think we can take

or marking it as broken

there isn't a way to do this on the aur as far as i know? but we still have tried to make sure everyone is aware here

I'm sorry but dismissing this as an "arch problem" is not very helpful

of course not, but there isn't much we really can do to help. the aur isn't exactly meant for binaries
alternatives like making our own binary distribution specifically for arch also aren't really viable, as abi breakages are very common

in the OP it's stated that you want to switch once the "vast majority" of users have a good experience with Qt6

i wouldn't consider this an issue with qt 6, but a distribution one. qt 6 itself will give you a great experience on more viable platforms for binaries like the chaotic aur, flathub, etc.

[getchoo]

Maybe we should just deprecate the prebuilt tarball and start shipping Qt in our portable builds

i think this would be a good way to go. not much breakage either, since i really don't know of any downstream packages that use it besides prismlauncher-{,qt5-}bin

maybe something for a new issue?