Plan for v5.0.0

[sledgehammer999]

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.

[Chocobo1]

The 4.4.x series will be supported at least until the summer of 2022.

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).

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.

I'm fine with it.

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.

I'm fine with it generally (with 4.4.x changed to 4.x).

[glassez]

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).

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.

[sledgehammer999]

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).

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.

[Chocobo1]

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.

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).

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.

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. Note that (under my suggestion) if 4.4.x doesn't have many regressions then we might move to 4.5 sooner (or even 4.6) than what you've planned. However, we can target "dropping qt5 support" to 5.0 release and make the 5.0 release at whatever time you see fit (or you insist it happens at 4.5, fine for me).

[glassez]

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?

if 4.4.x doesn't have many regressions then we might move to 4.5 sooner (or even 4.6) than what you've planned. However, we can target "dropping qt5 support" to 5.0 release and make the 5.0 release at whatever time you see fit

👍

[Chocobo1]

(i.e. first and second number), right?

Yes.

[sledgehammer999]

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. If you want to continue supporting it for more time, then it is totally fine by me (and preferable).

[Chocobo1]

If you want to continue supporting it for more time, then it is totally fine by me (and preferable).

As for myself, as long as the CI can build with Qt5 I have no problem supporting it.

[Dnkhatri]

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.

[glassez]

If you want to continue supporting it for more time, then it is totally fine by me (and preferable).

As for myself, as long as the CI can build with Qt5 I have no problem supporting it.

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.

[ghost]

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.

[sledgehammer999]

@vxiiduu this is interesting. What do you mean by compatibility pack? Do you patch the Qt6 source to restore Windows 7 support? If so, then the community at large might benefit from you publishing the patches anyway.

[ghost]

@vxiiduu this is interesting. What do you mean by compatibility pack? Do you patch the Qt6 source to restore Windows 7 support? If so, then the community at large might benefit from you publishing the patches anyway.

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. I am working on a more advanced project which does the same thing but doesn't require the user to copy paste a bunch of files. When that is in a workable state I will put it up on github with source. This will work with a wide range of applications that don't work on Win7, including almost all Qt6 applications.

[sledgehammer999]

@vxiiduu oh, something like an emulation layer

[ghost]

@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.

[Pentaphon]

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.

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

https://github.com/qbittorrent/qBittorrent/discussions/17094

[glassez]

Jumping from 4.5.x to 5.0.0 will just make the community think this project is being rushed.

The increase in the major version number is simply timed to coincide with the transition to Qt6.

[Pentaphon]

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

[Pentaphon]

Libtorrent 2.x needs a lot of bugfix I think.

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.

[xavier2k6]

@sledgehammer999 Could we get updated stats, perhaps March 2021 - October 2022 from @FossHub like we got in https://github.com/qbittorrent/qBittorrent/issues/14515#issuecomment-793123432 to see where the user base is at in relation to Windows 7/8? (we now also have Windows 11)

Edit: Pinged FossHub to send updated info to sledgehammer999

Some info in relation to windows 7/8/8.1 browser support. https://learn.microsoft.com/en-us/deployedge/microsoft-edge-supported-operating-systems https://support.google.com/chrome/thread/185534985/sunsetting-support-for-windows-7-8-8-1-in-early-2023?hl=en

[AlexeiScherbakov]

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:

1. Filtering torrents in main window, when torrents are rehashing after startup
2. Sorting torrents in main window, when torrents are rehashing after startup
3. Filtering torrents after adding new torrent

[glassez]

I tried Qt5 & Qt6

What version of qBittorrent did you test?

[AlexeiScherbakov]

4.4.3.1 x86 Qt6 - I just started it and UI freezed

UI shouldn't become unresponsible it must show something like spinner

[glassez]

4.4.3.1 x86 Qt6

v4.5 will include several performance improvements including revamped startup handling.

[xavier2k6]

Before Official release, we'd probably need to bump CMake to 3.22 or at least discuss raising it...

NOTE: https://bugreports.qt.io/browse/QTBUG-104352

Version 3.16 and newer (3.17 and newer for -debug-and-release builds 3.21 and newer for -static builds).

https://doc.qt.io/qt-6/windows-building.html#step-2-install-build-requirements.

EDIT: Also, we should probably require Windows 11 SDK 22000 as a minimum requirement to build on Windows with MSVC.

[Kissaki]

What is the scope/intention of this ticket? The original description is outdated.

The 4.4.x series will be supported at least until the summer of 2022.

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?

[glassez]

What is the scope/intention of this ticket? The original description is outdated.

The 4.4.x series will be supported at least until the summer of 2022.

The 4.4.x series will be supported at least until the summer of 2022.

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?

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.

[glassez]

@sledgehammer999, @Chocobo1, @qbittorrent/bug-handlers Since Qt v6.4 is released, I think it makes sense to collect some statistics about its work in order to decide whether it is ready for making productive builds of qBittorrent.

[FrancescoCardone]

Hi there :) Are you planning to add a dark theme/mode switch?

[Pentaphon]

Hi there :) Are you planning to add a dark theme/mode switch?

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.

[xavier2k6]

Since Qt v6.4 is released, I think it makes sense to collect some statistics about its work in order to decide whether it is ready for making productive builds of qBittorrent.

@glassez What kind of stats are you looking for? BTW Qt 6.4.1 has now been released.

[xavier2k6]

@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.

• It will be probably be qBittorrent builds with Qt6.4.x onwards only.
• It will also require windows 10 Build/Version >=1903.
• Possibly changing default theme of qBittorrent to use fusion style (on windows at least imo)
• It may also probably require re-jigging of some icon/text colors. (transfer list etc.)

I would like to keep any future discussions of dark mode in the relevant issue thread/threads.

Edit: Dark Mode (Native Support) #17081 Dark theme out of the box #15288

[glassez]

@glassez What kind of stats are you looking for?

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)?

[xavier2k6]

See: https://github.com/qbittorrent/qBittorrent/issues/17249#issuecomment-1279968360

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?!

[gennaios]

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 https://doc.qt.io/qt-6/macos-issues.html

[Pentaphon]

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.

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.

[gennaios]

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

[xavier2k6]

(As of Qt 6.6) - The minimum CMake version for Qt on Apple platforms is now CMake 3.21.1.

Bump CMake requirements on Apple platforms The minimum CMake version for Qt on Apple platforms is now 3.21.1.

https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/6.6.0/release-note.md

---

CMake (>= 3.16, >= 3.18.4 for Ninja Multi-Config, >= 3.19 for WebEngine, >= 3.21.1 for static Qt builds in Qt 6.2+, or builds for Apple platforms in Qt 6.6+)

https://wiki.qt.io/Building_Qt_6_from_Git

---

CMake (>=3.16, >= 3.18.4 for Ninja Multi-Config, >= 3.21.1 for static Qt builds or building for Apple platforms)

https://doc.qt.io/qt-6/macos-building.html

---

@glassez @Chocobo1 @thalieht @sledgehammer999

Before Official release, we'd probably need to bump CMake to 3.22 or at least discuss raising it...

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) https://repology.org/project/cmake/badges https://www.scivision.dev/cmake-changelog/

[ayyyiieneheuihues]

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 😃

[ayyyiieneheuihues]

@ayyyiieneheuihues

Just look at the milestones page to see what's planned or currently been added so far.

https://github.com/qbittorrent/qBittorrent/milestones

Some changes mentioned in v5.0.0 milestone are closed and have red icon, so you should look at only merged ones with purple icon to see what's included so far. Some changes might be even reverted, so can't be always certain that all get included in upcoming release.

https://github.com/qbittorrent/qBittorrent/milestone/66?closed=1

Major changes I guess are Dark theme for desktop client and WebUI users and having no built-in Qt5 support left and so only builds with Qt6 for everyone.

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.

[xavier2k6]

There is currently no viable enforcement of minimum supported macOS in master which needs to be discussed & indeed any future releases for the macOS platform.

[luzpaz]

Is there a discussion thread for this yet ?

[Pentaphon]

It's been nearly a month since

Keep an eye out for an alpha release of qBittorrent 5.0.0 sometime this week or the next one.

Any chance of an alpha this Sunday?

[xavier2k6]

Is there a discussion thread for this yet ?

Not yet, I haven't got around to it & provide more info.

Any chance of an alpha this Sunday?

It will be out when it or maintainer is ready.

[xavier2k6]

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.

---

v5 Plan status to date:

• [x] Drop support for < Windows 10 1809 (Min. Qt 6 Req.)
• [x] Drop support for Qt 5
• [ ] Drop support for libtorrent < 2.x

Propose:

macOS

• [ ] Bump CMake requirement to 3.21.1+ (https://github.com/qbittorrent/qBittorrent/issues/15940#issuecomment-1763060218)
• [ ] Set/Enforce Minimum supported macOS version [TBD] - (No effective enforcement of Min. macOS in master)

In-General:

• [ ] Use SQLite by default

[Pentaphon]

v5 Plan status to date:

• [ ] Drop support for libtorrent < 2.x

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.

[glassez]

Guys, why continue to trash this very outdated post? Just look at https://github.com/qbittorrent/qBittorrent/pull/20443.

[xavier2k6]

@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.

[xavier2k6]

There is currently no viable enforcement of minimum supported macOS in master which needs to be discussed

• 20459

[Pentaphon]

Guys, why continue to trash this very outdated post?

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.