Steps to Qt6

[glassez]

I believe that the transition to Qt6 will not be instantaneous and we will need to support both Qt5 and Qt6 for some time. So I suggest discussing here the main incompatibilities between Qt5 and Qt6, as well as the steps we should take to add initial support for Qt6. I suggest that we start preparing the codebase by cleaning up the use of deprecated features, for which there are replacements in Qt5. Unfortunately, many of them are deprecated in later Qt5 versions (5.14 and 5.15), so we will still have to add a lot of conditional code (since we will not be able to abandon the use of earlier Qt5 versions so quickly).

[glassez]

@sledgehammer999, @Chocobo1, @qbittorrent/frequent-contributors, @qbittorrent/bug-handlers, please participate.

[glassez]

QStringRef

I'm thinking about how to get rid of the use of deprecated QStringRef class (we use it mainly via QString::splitRef()). There is an obvious solution for Qt6, which is to use QStringView. But although it is available since Qt 5.10, there is still a problem to write compatible code, since even in Qt 5.15 it does not have a fully compatible interface with its counterpart from Qt6 (in particular, there is no method QStringView::split() that I intended to use). So we probably have to write a lot of conditional code in this case. However, I have an idea to implement some utility (QVector<QStringView> Utils::String::splitView()) that will hide this conditional code, significantly reducing its quantity. What do you think about it?

[xavier2k6]

Points to note:

https://github.com/qbittorrent/qBittorrent/pull/13937

https://github.com/qbittorrent/qBittorrent/issues/12417#issuecomment-691215354

[glassez]

even in Qt 5.15 it does not have a fully compatible interface with its counterpart from Qt6 (in particular, there is no method QStringView::split() that I intended to use).

Unfortunately, this turned out to be even worse than I had previously assumed. Qt5 QStringView is even more flawed (in particular, it does not have any parsing methods, such as toInt()), so even implementing the splitView() function mentioned above will not be enough to solve the incompatibility problem.

[FranciscoPombal]

I disagree with the overall approach. I think we'd be better off migrating at once, even if it takes some time. The downside is that some users would not have access to new versions for a long time (thinking mainly of Ubuntu 20.04 LTS users here). So, we should ensure at least that whatever version we're going to leave 20.04 users stuck on until next year doesn't have too many annoyances.

From my own personal use, the curren versions seem OK, but I haven't looked at the issue tracker for the past 2 months so I have no idea if there are frequent issues that users are experiencing - will look into that.

Regardless, assuming everything else is OK, I think it's going to boil to down to whether we want to migrate to Qt6 before or after finishing up BT v2 support. That is one of the most wanted features, and I think for many users it would be quite annoying to get stuck without v2 for another year. On the other hand, that kind of result sort of comes with the territory of using Ubuntu LTS, so....

[glassez]

I disagree with the overall approach. I think we'd be better off migrating at once, even if it takes some time.

You're too radical (as always). However, I tried this problem a bit, so I made sure that it is not so easy to have a codebase that is simultaneously compatible with both Qt 5 and 6 versions, at a minimum it will require a lot of conditional code. But I still strongly disapprove of the idea of dropping Qt5 so soon. The only compromise I can see is to create a separate branch for Qt6 support while v4.x development will continue based on Qt5 until a new version (say qBittorrent v5.0) is stable enough. This way we will be able to release test alpha and beta (Qt6) builds in parallel with the main (Qt5) releases. You can say, of course, that someone could just post PR that implements Qt6 support and then improve it until it's good enough. But I am convinced that it will be extremely inconvenient both for joint contributions to it, and for testing.

[xavier2k6]

The only compromise I can see is to create a separate branch for Qt6 support while v4.x development will continue based on Qt5 until a new version (say qBittorrent v5.0) is stable enough.

How about create a branch for v5_x_x which will focus on Qt6 & libtorrent 2.x.x?

Edit: Maybe even make it 64-bit exclusive??

[glassez]

How about create a branch for v5_x_x which will focus on Qt6 & libtorrent 2.x.x?

I wouldn't mix libtorrent2 and Qt6. Support of libtorrent2 can be implemented independently.

Maybe even make it 64-bit exclusive??

IIRC, Qt6 doesn't support 32-bit in either way.

[xavier2k6]

IIRC, Qt6 doesn't support 32-bit in either way.

True - my brain's a bit fried.....

Doesn't support Windows 7/8//8.1 either.... (Need to discuss minimum Windows 10 supported Build in future too, so we can raise NTDDI_VERSION) - I thinks this applies now even!

[FranciscoPombal]

@glassez

You're too radical (as always).

The solution I'm proposing is rather unprecedented, yes, but in my eyes the trade-off seems worth it. I've already looked a bit into this, and honestly it seems like it would be a giant mess to support both Qt versions at the same time - on this, we agree:

However, I tried this problem a bit, so I made sure that it is not so easy to have a codebase that is simultaneously compatible with both Qt 5 and 6 versions, at a minimum it will require a lot of conditional code.

But the alternative you suggest doesn't sound like an alternative at all, just the same thing with extra steps:

The only compromise I can see is to create a separate branch for Qt6 support while v4.x development will continue based on Qt5 until a new version (say qBittorrent v5.0) is stable enough. This way we will be able to release test alpha and beta (Qt6) builds in parallel with the main (Qt5) releases.

For instance, we would constantly have to think about backporting patches from one branch to the other, which sounds like a massive headache. I think it's unrealistic to commit to supporting 2 versions.

But I still strongly disapprove of the idea of dropping Qt5 so soon.

But why, specifically? I think it is important for you to elaborate on that, so that I and others can understand where you're coming from. In my previous post, I reflected on the "why" and ultimately deemed acceptable that basically only Ubuntu PPA users would suffer from an unusually long upgrade wait time (>= 1 year). If you think that dropping support for Windows 7/8/8.1/some EOL macOS version is a problem... well... you already know what I think about that (even more ironic as we're about to drop support for Ubuntu 18.04)...

Surely, porting to Qt6 would take at least some months, but hopefully not more than the long hiatus of last year. We are in a much better position than last year - we have better infrastructure (CI artifacts), new active members on the team, maintainership situation clarified, etc. And even if it took a lot of months - hey, it's a port to another major Qt version. Most users understand that.

You can say, of course, that someone could just post PR that implements Qt6 support and then improve it until it's good enough. But I am convinced that it will be extremely inconvenient both for joint contributions to it, and for testing.

This is a good point. Collaboration could be a challenge. But suppose you were one of the people at the helm of such a PR - what would you like to change to make the following easier:

• joint contribution?
• testing?

I should point out that, compared to the same time last year (just as a point of comparison), there have been improvements to both of those aspects already:

• joint contribution: the file health script prevents annoying conflicts and diff bloating. For instance If contributor A commits trailing spaces, if contributor B has their editor set to trim trailing spaces on save, B will then either commit spurious changes, or tell contributor A to fixup, or fixup themselves.
• testing: we now have CI that produces artifacts that users can test (especially our largest demographic, Windows users). We're no longer constrained by having to wait on someone to provide a test build on their own time. As we're porting to Qt6, we can post updates about it and calls for testing on the forum/discussions/website. I'm sure there would be no shortage of people providing feedback.

How about create a branch for v5_x_x which will focus on Qt6 & libtorrent 2.x.x?

I wouldn't mix libtorrent2 and Qt6. Support of libtorrent2 can be implemented independently.

Agreed, only one big change at a time.

[jagannatharjun]

Qt6 doesn't support 32-bit in either way.

are we sure to drop 32-bit support. It has over a hundred thousand downloads on Sourceforge also consider its secondary download source

IMHO Qt6 doesn't provide/plan to provide anything in their widget module to worth anyone's effort for maintenance.

[xavier2k6]

are we sure to drop 32-bit support. It has over a hundred thousand downloads on Sourceforge also consider its secondary download source

I would say yes! - we won't be moving to Qt 6.x until the end of the year, possibly even this time next year. (Previous target was when Qt6 hit it's first LTS (September 2021) or possibly 2nd LTS)

Also looking at Sourceforge/secondary source doesn't prove that all those users are running 32-bit OS - you just have to look at some of the crash reports to see that users are running the 32-bit version on a 64-bit OS.

In my opinion, it's more of a convenience thing for people to just click the first link available etc.

We should look at "real-world" examples of what Windows OS Version users are using such as steam

https://store.steampowered.com/hwsurvey?platform=pc

[xavier2k6]

IMHO Qt6 doesn't provide/plan to provide anything in their widget module to worth anyone's effort for maintenance.

We won't get anymore updates for Qt5 Series for about a year anyway over their corporate LTS stance.

What if Qt 6.x fixes something that is broken for users?? (HiDPI etc.)

[jagannatharjun]

@glassez Since you opened a PR targetting v5, IMHO you should open a separate issue with expected goals and related discussions on the major release.

[glassez]

IMHO you should open a separate issue with expected goals and related discussions on the major release.

I'm sorry, I'm not going to do more than I do yet. My goal for now is just to add preliminary support of Qt6 (simply put, make qBittorrent build with Qt6) so that someone can start doing pre-tests. v5 means for now only that switching to Qt6 is a long-term (no ETA) plan. Although I would really increase the major number when switching to Qt6 (upgrading framework is enough reason for it).

Someone can open any Issue about it if it's something to say about.

IMHO Qt6 doesn't provide/plan to provide anything in their widget module to worth anyone's effort for maintenance.

Personally, I care the least about widgets. But here are a lot of the core changes I really like.

[FranciscoPombal]

are we sure to drop 32-bit support. It has over a hundred thousand downloads on Sourceforge also consider its secondary download source Also looking at Sourceforge/secondary source doesn't prove that all those users are running 32-bit OS - you just have to look at some of the crash reports to see that users are running the 32-bit version on a 64-bit OS.

In my opinion, it's more of a convenience thing for people to just click the first link available etc.

We should look at "real-world" examples of what Windows OS Version users are using such as steam

https://store.steampowered.com/hwsurvey?platform=pc

Finally someone gets it. Plus we know that 32-bit is the cause of some problems that are simply not there in the 64-bit version.

[xavier2k6]

In relation to current Qt support (Qt 5.15.2/Windows)

Are there plans to cherry pick certain Qt fixes & integrate them due to Qt 5.15.3+ now being LTS & released for Commercial users only or will qBittorrent remain with "vanilla" Qt?

[FranciscoPombal]

@xavier2k6

In relation to current Qt support (Qt 5.15.2/Windows)

Are there plans to cherry pick certain Qt fixes & integrate them due to Qt 5.15.3+ now being LTS & released for Commercial users (...)?

That would require a commercial license, so no.

[sledgehammer999]

It is my understanding that this is a bit of a clusterfuck to be honest. As it was already described incompatibilities between Qt5 and Qt6 already make this a mess. Also add to the fact that Windows 7 still has a pretty sizable chunk of market share (first google result) and that Qt6 doesn't support it.

For the time being I suggest to focus our efforts/time into these 2 directions:

1. Better libtorrent 2.0.x compatibility (this is probably more fundamental than our GUI library of choice)
2. Start with the low hanging fruit between Qt5 and Qt6. Eg drop deprecated stuff in Qt5, use common Qt5/Qt6 APIs, use APIs that require minimal conditionals between Qt5/6. Then towards the end of the year we will reexamine the situation. Maybe Qt6 is still lagging for widespread usage. Or maybe it is ok and in the meantime Windows 7 usage has dropped significantly etc.

libtorrent 2 and Qt6 are pretty big beasts to try and tackle simultaneously. So I would prefer to give preference to libtorrent-2 compatibility.

Also looking at Sourceforge/secondary source doesn't prove that all those users are running 32-bit OS - you just have to look at some of the crash reports to see that users are running the 32-bit version on a 64-bit OS.

It doesn't prove that all users are running 32-bit. It proves how many of them do and the overall size of their chunk in ours users.

In my opinion, it's more of a convenience thing for people to just click the first link available etc.

That may be true, I am not so against in dropping 32bit in the future.

We should look at "real-world" examples of what Windows OS Version users are using such as steam

Oh come on! Steam has heavily skewed stats. Gamers usually have cutting edge hardware and the latest Windows version (usually forced to do this by new games). And I don't think that all our users are hardcore gamers.

[sledgehammer999]

Are there plans to cherry pick certain Qt fixes & integrate them due to Qt 5.15.3+ now being LTS & released for Commercial users only or will qBittorrent remain with "vanilla" Qt?

It is LTS only for paying customers. The rest of us don't get the sources for new releases on Qt 5.15. That's why the community is angry with them.

[glassez]

this is probably more fundamental than our GUI library of choice

Am I the only one who doesn't treat Qt like "GUI-only library"?

Start with the low hanging fruit between Qt5 and Qt6. Eg drop deprecated stuff in Qt5, use common Qt5/Qt6 APIs, use APIs that require minimal conditionals between Qt5/6.

As mentioned above, there will still be a lot of differences here even if we move to Qt-5.15 and get rid of all the deprecated features there. For example, the absence of a full-fledged QStringView type will generate a bunch of unreadable conditional code.

Anyway I'm not going to force it. I want to finish my work in this direction by getting our codebase pre-compatible with Qt6 so that it compiles successfully with it and someone can start testing it. And then we'll see what to do next.

[xavier2k6]

I think outside of Qt 6.x/libtorrent 2.x.x - we need to have separate discussions about dropping 32-bit support which has it's own issue thread -> #12417 & are we going to continue supporting 11 soon to be 12 different builds of windows 10 as well......(We should raise the minimum supported version of this prior to Qt 6, it needs to be raised for that in any case)

[glassez]

Better libtorrent 2.0.x compatibility

14503 should open the gate there. At the very least, I will fully migrate my development environments to use libtorrent2 once it is merged.

[sledgehammer999]

Am I the only one who doesn't treat Qt like "GUI-only library"?

Ok, I was exaggerating a bit.

As mentioned above, there will still be a lot of differences here even if we move to Qt-5.15 and get rid of all the deprecated features there. For example, the absence of a full-fledged QStringView type will generate a bunch of unreadable conditional code.

I meant to converge as much as possible without any undue burdens like the QStringView/Ref parts you mentioned. The easy parts (if they exist).

[glassez]

The easy parts (if they exist).

There is not much left that we can do in this direction. One is replacing QString::SplitBehavior with Qt::SplitBehavior when we reach Qt 5.14. The second one is we should find a replacement for QNetworkConfigurationManager if this functionality is really important for qBittorrent. Well, plus some less obvious things (due to changes in the core of the framework) that are exposed in the process of working on #14465.

[xavier2k6]

QNetworkConfigurationManager

Just as a "refresher" https://github.com/qbittorrent/qBittorrent/issues/12970

[glassez]

In connection with the above, the question of the dropping the support of old Qt5 versions becomes relevant. So far, we have agreed that v4.4 will drop everything up to Qt 5.12 (#14427). But what's next? When can we reach Qt 5.15?

[FranciscoPombal]

@sledgehammer999

libtorrent 2 and Qt6 are pretty big beasts to try and tackle simultaneously. So I would prefer to give preference to libtorrent-2 compatibility.

I agree, and this seems to be the direction we are going in anyway.

It is my understanding that this is a bit of a clusterfuck to be honest. As it was already described incompatibilities between Qt5 and Qt6 already make this a mess. Also add to the fact that Windows 7 still has a pretty sizable chunk of market share (first google result) and that Qt6 doesn't support it.

Oh come on! Steam has heavily skewed stats. Gamers usually have cutting edge hardware and the latest Windows version (usually forced to do this by new games). And I don't think that all our users are hardcore gamers.

And statcounter doesn't? Remember that statcounter includes lots of stuff that heavily skews the results, like enterprise machines, POS, the computer that was gifted to granny 10 years ago, etc which tend to run way more legacy stuff than most people. I'm willing to be we have much more overlap with gamers. Plus this isn't the 90s/early 2000s anymore, a lot of people game now, casually or not (reminder: gaming is now the largest entertainment industry by revenue, even surpassing the movie industry), which means it's not just the "hardcore gamers" who have the incentive to upgrade more often because of games. Plus, in the last decade more and more incentives have appeared for even "non-gamers" to upgrade more often - and this shows. Windows 10 is now almost 6 years old, and if you look around you, you'll see that the vast majority of "normal" people are actually running Windows 10 on their laptops/desktops. Those still running 7 or 8 are a minority, and even within that group, only a smaller minority still owns a machine that wouldn't run Windows 10 x64 acceptably, and are just stubbornly holding on due to older Windows versions due to "privacy" (lol) or forced updates (not a problem anymore, but then again it was only ever a problem for people who held back on updates for several months at a time without good reason to do so), or some other non-reason.

Microsoft doesn't even officially support a lot of older Windows 10 builds anymore, as pointed out above (Windows 10 now more closely resembles a rolling-release distro). I've said many times before: if they don't neither should anyone else (unless bound by some legal contract or something like that). We should just produce builds and accept bug reports for modern platforms. Users still on those platforms can use older qBittorrent versions that still support them. They work fine and won't magically stop working the moment we release a new version that's not compatible with those older platforms.

@glassez

Am I the only one who doesn't treat Qt like "GUI-only library"?

No, and I agree it is dangerous to think of it in that limited way.

14503 should open the gate there. At the very least, I will fully migrate my development environments to use libtorrent2 once it is merged.

Too soon? There will still be at least another RC_1_2 release (1.2.13). Maybe we should ask @arvidn what are the plans for RC_1_2 for the future - how many more releases do you expect there will be for this branch?

Anyway, the last release of RC_1_2 happens soon, I think the last releases of the 4.3.x branch should use it (in other words, we I don't think we should ship something with RC_2_0 before with shipped something with the last iteration of RC_1_2).

There is not much left that we can do in this direction. One is replacing QString::SplitBehavior with Qt::SplitBehavior when we reach Qt 5.14. The second one is we should find a replacement for QNetworkConfigurationManager if this functionality is really important for qBittorrent. Well, plus some less obvious things (due to changes in the core of the framework) that are exposed in the process of working on #14465.

In connection with the above, the question of the dropping the support of old Qt5 versions becomes relevant. So far, we have agreed that v4.4 will drop everything up to Qt 5.12 (#14427). But what's next? When can we reach Qt 5.15?

I don't think it will be reasonable to abandon Qt 5.12 until at least April 2022 (because of Ubuntu 22.04 LTS) under the current paradigm and expectations we (implicitly) transmit to our users. That is why in some other thread I've proposed a more radical solution and conscious change of paradigm: We fully drop Qt5 ASAP (most probably, after 4.4.x which is for libtorrent 2.x migration) and start focusing exclusively on Qt6. The only users who will be meaningfully impacted are users of Ubuntu and other "stable" distros, who will have to wait almost a year in the worst case to be able to upgrade from 4.4.x (unless they want to install Qt6 themselves just for qBittorrent). But that's not a huge deal IMO - it would be much worse if they got stuck in a version without BitTorrent V2 support.

[sledgehammer999]

@FranciscoPombal I am not saying that Windows 7 isn't the minority. All I am saying is that it is a sizable minority and we shouldn't ignore and drop support yet. Maybe at the end of the year things have changed. Also MS dropping support for it isn't really meaningful to us if there are actually quite a few users out there. Hell, unless I am mistaken, in our entire toolchain only Qt6 is being a dickhead and dropping support for it. All other libs we use + compilers still support it. Libtorrent even supports (or supported until very recently) WinXP.

In connection with the above, the question of the dropping the support of old Qt5 versions becomes relevant. So far, we have agreed that v4.4 will drop everything up to Qt 5.12 (#14427). But what's next? When can we reach Qt 5.15?

As far as I can tell only Ubuntu is the one that drags us behind. We could take a more relaxed approach here just because we are dealing with Qt6. When Ubuntu 21.04 hits the market we can momentarily switch to 5.12 as planned. But after a few months and depending on our progress we can drop the LTS version and support 5.14/5.15. And then in October 21.10 gets released we drop 5.14.

[xavier2k6]

@sledgehammer999 Can we at least drop support for certain builds of windows 10?

We can use the "Issue Tracker" as a guide for "Our user base" etc.

https://github.com/qbittorrent/qBittorrent/pull/12574#issuecomment-723572888

[glassez]

14503 should open the gate there. At the very least, I will fully migrate my development environments to use libtorrent2 once it is merged.

Too soon?

Compatibility with native API is enough for me. Constantly switching between libtorrent branches is too burdensome for me. Everything else that you have said in this regard does not depend on it in any way. I believe v4.3.x should be based on libtorrent-1.2. And maybe even v4.4 will still be based on it (official releases), despite the support of libtorrent2, if any problems with libtorrent2 are known.

When Ubuntu 21.04 hits the market we can momentarily switch to 5.12 as planned.

Switching to Qt 5.12 is planned from the start of v4.4 branch independently from Ubuntu release cycle (if my previous comment was not so clear). All the following plan seems OK to me.

[sledgehammer999]

Can we at least drop support for certain builds of windows 10?

What do you mean? How do we do that? Or do you mean alongside dropping support for Win 7?

[xavier2k6]

Can we at least drop support for certain builds of windows 10?

What do you mean? How do we do that? Or do you mean alongside dropping support for Win 7?

We can use more fine-tuned NTDDI versioning from latest sdkddkver.h file from latest WINDOWS SDK

#define NTDDI_WIN7                          0x06010000
#define NTDDI_WIN8                          0x06020000
#define NTDDI_WINBLUE                       0x06030000
#define NTDDI_WINTHRESHOLD                  0x0A000000  /* ABRACADABRA_THRESHOLD */
#define NTDDI_WIN10                         0x0A000000  /* ABRACADABRA_THRESHOLD */
#define NTDDI_WIN10_TH2                     0x0A000001  /* ABRACADABRA_WIN10_TH2 */
#define NTDDI_WIN10_RS1                     0x0A000002  /* ABRACADABRA_WIN10_RS1 */
#define NTDDI_WIN10_RS2                     0x0A000003  /* ABRACADABRA_WIN10_RS2 */
#define NTDDI_WIN10_RS3                     0x0A000004  /* ABRACADABRA_WIN10_RS3 */
#define NTDDI_WIN10_RS4                     0x0A000005  /* ABRACADABRA_WIN10_RS4 */
#define NTDDI_WIN10_RS5                     0x0A000006  /* ABRACADABRA_WIN10_RS5 */
#define NTDDI_WIN10_19H1                    0x0A000007  /* ABRACADABRA_WIN10_19H1*/
#define NTDDI_WIN10_VB                      0x0A000008  /* ABRACADABRA_WIN10_VB */

alongside dropping support for Win 7

It can be done before that I believe.

(Just like how we can add per monitor v2 support via manifest file) if we really wanted to make further steps in supporting HiDPI/Dual Monitors etc.

[FranciscoPombal]

@FranciscoPombal I am not saying that Windows 7 isn't the minority. All I am saying is that it is a sizable minority and we shouldn't ignore and drop support yet. Maybe at the end of the year things have changed.

I don't think it is sizable at all, judging by the self-reported version in the issue reports of the past years. What's more, we have no obligation to keep shipping new versions to these users, especially if they are using platforms that huge companies have dropped support for. They can keep using old versions if they want. Maintaining support for this stuff is holding the rest of us back (users and contributors), and it is very annoying.

Also MS dropping support for it isn't really meaningful to us if there are actually quite a few users out there.

Of course it is. We should not be held hostage by users who refuse to upgrade, or who can't. We never promised we were a project focused on legacy platforms. And again, citation needed for "quite a few" - perhaps fosshub has some data on this, based on the user agents used to download ? (and even so, how many of those are simply stubborn users? I have some sympathy for those who genuinely can't upgrade, but not for those who refuse to; and again, the old versions won't magically break; those that need them can keep using them).

Hell, unless I am mistaken, in our entire toolchain only Qt6 is being a dickhead and dropping support for it. All other libs we use + compilers still support it. Libtorrent even supports (or supported until very recently) WinXP.

They are not being dickheads, they are just sane... it's not fun to support a platform that even its vendor no longer supports (unless that is specifically aim of your project, think restoration/vintage/revival). IIRC, libtorrent only supports XP/Vista

Support for XP was first dropped in libtorrent master 6 (!) years ago. https://github.com/arvidn/libtorrent/pull/21 https://github.com/arvidn/libtorrent/issues/5334#issuecomment-740592651

It still supports Vista by chance and because the userbase of libtorrent is different - the target audience is developers who tend to keep up, not "boomers" who post issues with those platforms because they stubbornly stay on such platforms, and who tend to understand the fact that if they are stuck on older platforms, then they are on their own and should stick to older versions: https://github.com/arvidn/libtorrent/issues/5334#issuecomment-740699794.

As far as I can tell only Ubuntu is the one that drags us behind. We could take a more relaxed approach here just because we are dealing with Qt6. When Ubuntu 21.04 hits the market we can momentarily switch to 5.12 as planned. But after a few months and depending on our progress we can drop the LTS version and support 5.14/5.15. And then in October 21.10 gets released we drop 5.14.

I disagree with aligning release cycles with non-LTS Ubuntu release. The vast majority of Ubuntu users are on LTS releases (can't find the source for this right now, sorry, but I am sure of this). So not guaranteeing alignment with LTS releases is basically the same of making no promises about Ubuntu support (in this case, 20.04 users would be left out in the could come October). At that point, might as well just drop Qt5 earlier like I suggested.

[FranciscoPombal]

Can we at least drop support for certain builds of windows 10?

What do you mean? How do we do that? Or do you mean alongside dropping support for Win 7?

alongside dropping support for Win 7

It can be done before that I believe.

It makes no sense dropping support for older Windows 10 builds and not dropping support for Windows 7/8/8.1 at the same time...

[FranciscoPombal]

FYI the minimum recommended CMake version when using Qt6 is 3.19.2, according to the Professional CMake book. It adds important features and bug fixes. So we'll need to bump that as well.

[sledgehammer999]

I created the following poll for user reporting their Windows version: https://github.com/qbittorrent/qBittorrent/issues/14515 It will run for quite a while*, and I'll put proper news entry with the next releases (coming soon). Spread the word.

*a while = a few months at the very least

[sledgehammer999]

wtf? I haven't created it a long time ago and it already has ~25 votes... I hope it is accurate enough.

[xavier2k6]

I created the following poll for user reporting their Windows version: #14515 It will run for quite a while*, and I'll put proper news entry with the next releases (coming soon). Spread the word.

*a while = a few months at the very least

I'd include the build versions for windows 10 as well as Qt 6 supports >1809 as target & they test on their CI with 2004.

(Unless, we're going to discuss that ourselves & decide accordingly)

[sledgehammer999]

Here is the breakdown that I was informed with from FossHub.

Period: January 2020 - March 2021 Unique visitors: 11,099,388 OS version	Percentage
Windows 10	86.00%
Windows 7	10.74%
Windows 8.01	2.46%
Windows XP	00.37%
Windows 8	00.30%
Windows Vista	00.13%
Windows Server 2003	00.01%
Windows NT	00.00%
Windows 2000	00.00%
Windows 98	00.00%

[xavier2k6]

Here is the breakdown that I was informed with from FossHub.

Period: January 2020 - March 2021 Unique visitors: 11,099,388

OS version Percentage Windows 10 86.00% Windows 7 10.74% Windows 8.01 2.46% Windows XP 00.37% Windows 8 00.30% Windows Vista 00.13% Windows Server 2003 00.01% Windows NT 00.00% Windows 2000 00.00% Windows 98 00.00%

So, this is close enough to the figures of https://gs.statcounter.com/os-version-market-share/windows/desktop/worldwide

The biggest elephant in the room is windows 7 so what we need to discuss now is if we wait until the introduction of Qt 6 do drop it or do we do it sooner.

Windows 8/8.1 don't really have the user base to support them any longer.

Perhaps, we can give a timeframe to users like what was announced previously for Drop of Support for < Windows 7

Monday November 19th 2018 - qBittorrent v4.1.4 release There will be 1-2 more releases in the 4.1.x series. After that we will switch to 4.2.x. The 4.2.x series will drop support for versions of Windows before Windows 7.

Just over a year later:

Tuesday December 3rd 2019 - qBittorrent v4.2.0 release WINDOWS: Drop support for < Windows 7 MACOS: Drop support for < macOS 10.10 (Yosemite)

[sledgehammer999]

Windows 8/8.1 don't really have the user base to support them any longer.

Disregard Windows 8/8.1. When Win 7 is dropped so are they.

Perhaps, we can give a timeframe to users like what was announced previously for Drop of Support for < Windows 7

Yeah, that was my initial thought. I am not going to make a proposal now. It is past midnight here and I don't have a clear mind.

[xavier2k6]

Yeah, that was my initial thought. I am not going to make a proposal now. It is past midnight here and I don't have a clear mind.

We also have to make the decision on 32-bit

[sledgehammer999]

Both 32-bit and Win7 droppage are tied with Qt6 adoption. So the same timeframe will apply to both of them.

[FranciscoPombal]

So, this is close enough to the figures of https://gs.statcounter.com/os-version-market-share/windows/desktop/worldwide

Statcounter has Windows 7 at 16.55% as of February 2021. That's around 50% more than the FossHub data. If anything, it is further proof that the statcounter stats are not relevant for us. As expected, they grossly overestimate the amount of users on older platforms. It's also no surprise that Steam's reported market share for Windows 7 is an underestimation for domains other than gaming, but honestly I wasn't expecting an underestimation by a factor of \~4x.

Perhaps, we can give a timeframe to users like what was announced previously for Drop of Support for < Windows 7

Monday November 19th 2018 - qBittorrent v4.1.4 release There will be 1-2 more releases in the 4.1.x series. After that we will switch to 4.2.x. The 4.2.x series will drop support for versions of Windows before Windows 7.

Just over a year later:

Tuesday December 3rd 2019 - qBittorrent v4.2.0 release WINDOWS: Drop support for < Windows 7 MACOS: Drop support for < macOS 10.10 (Yosemite)

A (forced) 1 year timeline (counting from now) is way too generous IMO. It's already been more than a year since Windows 7 was officially EOL'd. We should just say: "Support for Windows < 10 1809 and 32-bit should be dropped sometime later this year, whenever we finish the upgrade to Qt6" - and do the Qt6 upgrade at our own pace without additional constraints.

[xavier2k6]

A (forced) 1 year timeline (counting from now) is way too generous IMO.

I didn't say we give a year ("we can give a timeframe to users like what was announced previously") , I was merely stating that with perhaps the next release a statement is made (& gave the example above)

---

We discussed previously in another PR & The team's general consensus at the time was to implement Qt 6.x support in qBittorrent when the Qt 6 series had reached it's first/second LTS

Below is Qt 6 series timeline:

Qt 6.1 is scheduled for release in April 2021 Qt 6.2 LTS is scheduled for release in September 2021 (first long term supported version in the Qt 6 series)

That's 6 months from now (General timeframe)

[FranciscoPombal]

@xavier2k6

I didn't say we give a year ("we can give a timeframe to users like what was announced previously") , I was merely stating that with perhaps the next release a statement is made (& gave the example above)

We discussed previously in another PR & The team's general consensus at the time was to implement Qt 6.x support in qBittorrent when the Qt 6 series had reached it's first/second LTS

Below is Qt 6 series timeline:

Qt 6.1 is scheduled for release in April 2021 Qt 6.2 LTS is scheduled for release in September 2021 (first long term supported version in the Qt 6 series)

That's 6 months from now (General timeframe)

OK, I can live with about 6 months. But we should not impose on ourselves constraints based on the LTS status of the Qt releases, because LTS releases are for commercial users only now. For regular users, there is basically no distinction between an LTS and non-LTS release. No fixes are backported, so the only way to go is forward.

[xavier2k6]

But we should not impose on ourselves constraints based on the LTS status of the Qt releases, because LTS releases are for commercial users only now.

I think the thought of using the LTS as a timeframe was just that at the time of it's release, the Qt 6 series would have been matured.

[jagannatharjun]

@FranciscoPombal @xavier2k6 you have to understand that not everyone would like to use the latest and greatest but would choose to stick with a solution that just "works". in that sense, Windows 7 is a valid choice for a lot. even I would have stuck with it if I don't have to do dev work.

[Mazino-Urek]

I know my opinion won't matter here but here is a solution I can think of that might pull this off. It will be done in two-step.

Step 1: There will be a final 4. version that will be feature frozen forever. Qbittorent is already a full-fledged torrent client and new bells and whistles won't matter that much. It will be the final version to have QT 5 and support Windows 7 and 32-bit OS version. When the version QBT 5.0 is released its users won't be prompted to upgrade to the latest version rather stick with version 4. and only get minor releases. This version will not be abandoned though, it will only get critical bug fixes until the developers feel that the time has finally come to let it go.

Step 2: After the final 4.** version the whole development will be focused on QT 6 and the new features that devs want to implement.

By this method you guys can still support 32-bit OS and Windows 7 as long as you guys want. This is the only way this zero-sum game can be won as the development time precious here.

My two cents end now.