-
-
Notifications
You must be signed in to change notification settings - Fork 623
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Saying goodbye to Qt 5 #2324
Comments
Windows-MSVC-Legacy was already dropped in 8.0 |
Qt 6 is still broken on archlinux: #991 |
arch problem, compile prismlauncher yourself with the source aur package, it's not on our side that arch broke ABI compatibility |
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. |
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 |
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. |
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 |
I think simply removing the bin package from the aur (or marking it as broken) 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
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
of course not, but there isn't much we really can do to help. the aur isn't exactly meant for binaries
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. |
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 maybe something for a new issue? |
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.0Once 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
Unresolved Questions
Alternatives Considered
This suggestion is unique
You may use the editor below to elaborate further.
Related issues here!
NixOS/nixpkgs#305556 - nixpkgs deprecation
The text was updated successfully, but these errors were encountered: