Plan for v5.0.0 #15940
Comments
I would suggest making it 4.x series. If 4.4.x is stable to a point that it doesn't need any bug fix then we move on to 4.5.x (with new features).
I'm fine with it.
I'm fine with it generally (with 4.4.x changed to 4.x). |
Then the main question for me is, how will the master branch behave? I object to any policy that would prevent the merging of ready PRs. |
4.5.x is another major version. My rationale is that the next major version (whatever number it is called) will be Qt6 only. And instead of doing 4.5.x (as usual) we can jump to 5.x as the next major version. |
To summarize, no restriction for master branch. For any other branch (e.g. v4_4_x, v4_3_x), only bug fixes goes in (no new features, no refactors).
I don't have strong opinion on when to drop qt5, whether it be 4.x or 5.0. I only care that major changes comes with major version number bumps. |
I suppose you mean both major and minor (i.e. first and second number), right?
👍 |
Yes. |
|
To be clear: My whole point about dropping Qt5 is solely based on the assumption that we can't support both Qt5 and Qt6 for long (mainly due to time resources on your part). Personally, I don't mind providing builds for both on Windows (I already have the toolchains ready). That's why I set summer of 2022 as a point. |
As for myself, as long as the CI can build with Qt5 I have no problem supporting it. |
|
If you will be keeping qt5 version for older windows version if possible please release an appimage with qt5 for linux as well. The more I look at how things break with all the different versions of libraries on different versions of OS. The more Kovid's (Calibre Developer) decision to ship the libraries with the app instead of depending on the OS having the correct versions makes sense. |
If by keeping support you mean "don't remove existing support" from the code, then I agree. But I wouldn't want to limit myself from using the new Qt6 tools when adding something new. |
|
I have developed a compatibility pack to make the Qt6 version of qbittorrent have full function on Windows 7. I will release it when qbittorrent drops its official windows 7 compatible version, to allow other Win7 users to continue using the latest version if that is what is desired. |
|
@vxiiduu this is interesting. What do you mean by compatibility pack? Do you patch the Qt6 source to restore Windows 7 support? |
No, it redirects the system DLLs to add missing exports which Qt6 "needs". qBittorrent and it's dependencies are not touched or recompiled in any way.
|
|
@vxiiduu oh, something like an emulation layer |
not strictly speaking, it just adds extra functions on top of what the OS provides. I choose this method because it works with proprietary software as well as open source software and it's much easier than dealing with source code and other people's wacky build methods. It's also very unlikely, in my opinion, that qt maintainers would ever incorporate win7 support patches into their source code. |
I don't think there's any good reason to go to 5.0.0 in the near future. There's 2,800 unresolved issues and this project can spend a very long time resolving them before it gets to 5.0.0, which would have to involve a major change across all platforms. There's really no reason not to go to 4.6,x, 4.7.x and even 4.9.x before getting to 5.0.0, fixing as many bugs as possible along the way. Jumping from 4.5.x to 5.0.0 will just make the community think this project is being rushed. In short, I think this project needs a feature freeze until 5.0.0. qBittorrent has become immensely popular, but also quite buggy. Now that libtorrent 2.x is merged, it's time to stop adding new things and stomp out as many major bugs as possible. I've made a poll on the topic here and I think many people will agree that now is the time to start ONLY fixing bugs instead of even thinking about 5.0.0 |
The increase in the major version number is simply timed to coincide with the transition to Qt6. |
That seems like a trivial reason to jump a major version number. You could simply end Win7/8 support/Qt6 with 4.5.0. Anybody who sticks with Windows 7/8 probably isn't going to upgrade their torrent client either, so it makes more sense for them to be stuck with 4.4.x than to lure them with 5.0.0. If you're stuck with 4.4.x and you see 4.5.0 come out, you're probably not going to care as much about upgrading since it won't seem to be a huge release compared to 5.0.0. Going to 5.0.0 just because of dropping Win7/8 support is just going to make a bunch of WIn7/8 users come to github and complain that they can't get the much bigger sounding 5.0.0 release. We have 4.6, 4.7, 4.8, 4.9 after that to fix lots of major bugs and iron out all the issues with libtorrent v2 before a massive feature or design change to coincide with a major version number change to 5.0.0 |
Honestly, if we are going from 4.5 to 5.0 libtorrent 2.x should have been saved for 5.0. Libtorrent 1.2.x is actually in really good shape right now. 1,x is way better and I think the devs were pressured to go with 2.x because people thought they needed 2.x right now because of BT2.0 which really wasn't needed just yet. |
|
@sledgehammer999 Could we get updated stats, perhaps Edit: Some info in relation to windows 7/8/8.1 browser support. |
|
Please separate UI from IO wherever possible. I tried Qt5 & Qt6 - I had lot of situations where UI became unresponsible, while some torrents are rehashing:
|
What version of qBittorrent did you test? |
|
4.4.3.1 x86 Qt6 - I just started it and UI freezed UI shouldn't become unresponsible it must show something like spinner |
v4.5 will include several performance improvements including revamped startup handling. |
|
Before Official release, we'd probably need to bump CMake to NOTE: https://bugreports.qt.io/browse/QTBUG-104352
https://doc.qt.io/qt-6/windows-building.html#step-2-install-build-requirements. EDIT: |
|
What is the scope/intention of this ticket? The original description is outdated.
We are past summer now, and as far as I can see 5.0 has not been released yet, so end of support for 4.4 makes no sense? |
The 4.4.x series will be supported at least until the summer of 2022.
We already released beta of upcoming v4.5 series. The only reason it didn't get 5.0 version is that we still can't fully upgrade to Qt6 as previously planned. |
|
@sledgehammer999, @Chocobo1, @qbittorrent/bug-handlers |
|
Hi there :) |
Honestly that should be a major goal for 5.0 alongside the Qt6 change... They have plenty of versions to go through before getting to 5.0 so it could be added to the milestone. |
@glassez What kind of stats are you looking for? BTW Qt 6.4.1 has now been released. |
|
@FrancescoCardone @Pentaphon dark mode (for windows) has been brought up/discussed previously. There has been a huge improvement by Qt for us to enable this by default in a future release.
I would like to keep any future discussions of dark mode in the relevant issue thread/threads. Edit: |
Statistics of the results of its use. Are there still "childhood diseases" that previously prevented the qBittorrent from using it by default (and then dropping support of Qt5 completely)? |
|
See: #17249 (comment) I haven't noticed any problems since (above issue comment)....can you give me a refresher on some of the blocking issues for dropping Qt5?! |
|
I haven't been following the discussion and haven't found such in some searching. For either 5.x or someday, are there plans for a more native looking UI, particularly on macOS? Since Big Sur I believe, there is a new toolbar look. Most apps adopt it. This is Transmission:
I'm not sure if this is the setting. https://doc.qt.io/qt-6/qmainwindow.html#unifiedTitleAndToolBarOnMac-prop This is the new sidebar look, with apps putting the search field either in the main toolbar (as either a field or an icon that animates out to a field) or at the top of the side bar:
Contrast this screenshot of qBittorrent on my system to compare scale of icons or fonts.
In System Preferences/Settings, there is a system wide setting for sidebar font size (small, medium, large). There is also the alert style dialog which I believe came with Qt6. I haven't tested that out and it may already be automatic.
For icons, there is the SF Symbols font used by most apps on both macOS and iOS. I imagine perhaps on each platform, perhaps there are icons that look more native either with a particular window manager on Linux (maybe?) or on Windows. There may be various little things such as Qt6 providing better support out of the box; perhaps there are options I'm unaware of. Yet mainly I'm thinking of the main UI as what stands out the most. For possible other issues: Qt for macOS - Specific Issues |
You'd have to find somebody with a lot of Mac experience that is willing to take on such a project. Transmission is getting a lot of Mac support because it is a historically Mac and Linux client while qBittorrent has mostly Windows and Linux users. |
|
It seemed as such; and I vaguely recall reading somewhere there isn't anyone devoted to macOS so far. For future reference, I found something regarding icons on macOS but there maybe more. I may open up a new issue for macOS in general in case someone reads it someday and wishes to tackle such. https://bugreports.qt.io/browse/QTBUG-102346?jql=text%20~%20%22sf%20symbols%22 |
|
(As of Qt 6.6) - The minimum CMake version for Qt on Apple platforms is now CMake 3.21.1.
https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/6.6.0/release-note.md
https://wiki.qt.io/Building_Qt_6_from_Git
https://doc.qt.io/qt-6/macos-building.html @glassez @Chocobo1 @thalieht @sledgehammer999
What do you think? I had chosen CMake 3.22 previously as it's default/minimum on our CI - Linux (Ubuntu 22.04 - 3.22.1) |
|
Hi, I am trying to find what is up and coming for the 5.0.0 version of qBittorrent because the alpha being introduced next week was mentioned in the news section of qbittorrent.org. I couldn't find anything in the "Discussions" section of this project but managed to find this issue. In the 4.6.0 release that was made on Oct 22 2023 Qt 5 support was dropped for Windows and only Qt 6 and Windows 10+ are now supported. According to the original post of this issue shouldn't we be in 5.0.0 by now then? What will be new in 5.0.0 when it comes out? I saw libttorrent 2 mentioned in this thread so is that still on the roadmap for 5.0.0? What else can we expect? Clarification here would be greatly appreciated. Thanks 😃 |
Oh okay, thank you. I'm new to collaborating on open source projects on GitHub. I see there is a bunch of closed milestones to update the WebUI. Not that many to update the WebAPI though. I will create a separate issue for a performance improvement I need to /api/v2/torrents/info that I think I can change to torrentscontroller.cpp. I just don't really like C++ and all the different conventions. |
|
There is currently no viable enforcement of minimum supported macOS in |
|
Is there a discussion thread for this yet ? |
|
It's been nearly a month since
Any chance of an alpha this Sunday? |
Not yet, I haven't got around to it & provide more info.
It will be out when it or maintainer is ready. |
v5 Plan status to date:
Propose:macOS
In-General:
|
I don't think libtorrent 2.x has improved enough to be the only option for 5.0.0. We all saw the issues people had with libtorrent v2 in the 4.4.x series and that was libtorrent 2.0.7 compared to the recent 2.0.10 release. Attempting to bring v2 back to default is probably a mistake. I think we should wait until Arvid releases a major update like libtorrent 2.1.x before dropping libtorrrent v1 support. |
|
Guys, why continue to trash this very outdated post? |
|
@glassez TBH (for me) that's about the "changelog" (changes that have already been made) & I believe this ticket is still relevant as it's about the Plan for v5.0.0 i.e. what hasn't been done yet & what needs to be done etc. |
|
Because it's still open and refers to the overall plan about 5.0.0 aka figuring out stuff before it happens. That other post is about the changelog, which is almost entirely stuff that has already been committed. @xavier2k6 what do you think about my concerns with dropping libtorrentv1 support? I don't think libtorrentv1 should be dropped until Arvid starts rolling out stable libtorrent 2.1.x builds to ensure that major changes have been made to resolve the issues that many people have been having with libtorrent 2.x since qBittorrent 4.4.x when v2 debuted and also had to be rolled back from being default. |
|
My initial post is outdated. I don't want anymore the drop for lt 1.2.x. |
|
Would be cool if on WEB UI (linux vers) you guys add " skip hash check on torrent add " so you can cross-seed automatic instead of check with huge amount of cpu resources every torrent |
? |
and others
The current plan is this:
The 4.4.x series will be supported at least until the summer of 2022.
The next major version (v5.0.0) will drop support for Qt5 and therefore for Windows 7 and 8. Unfortunately, I don't think we can reasonably continue supporting Qt5/Win7 anymore.
Of course, support for libtorrent 1.2.x will be dropped too. It may be dropped in 4.4.x depending on circumstances and how well 2.0.x is received by the userbase.
The text was updated successfully, but these errors were encountered: