Qbittorrent qt6 что значит

Qbittorrent qt6 что значит

Текущая версия: 4.5. 2 (28.02.2023)
Changelog

Билды с libtorrent 1 (по состоянию на 2022 год) в некоторых случаях (раз, два) потребляют меньше CPU и RAM чем билды с libtorrent 2.

Билдам основанным на Qt6 необходима Windows 10+. Не имеет проблем с маштабированием/hidpi(4k) мониторами

qBittorrent — абсолютно бесплатный, без рекламы, мощный и простой при работе клиент файлообменной сети BitTorrent. Несмотря на кажущуюся простоту, программа обладает внушительным набором весьма полезных возможностей, как например наличие интегрированной поисковой системы, расширяемой за счет плагинов, поддержка UPnP/NAT-PMP, встроенный менеджер ограничения скорости, фильтрация по IP, удаленное управление через веб-интерфейс, а также наличие опции последовательной закачки.
Имеется выборочное скачивание файлов из торрента, опция последовательной закачки для предпросмотра недокачанных медиафайлов (в этом режиме файл качается начиная с начала и заканчивая концом, а не хаотично, что дает возможность начать смотреть фильм еще до того, как он полностью скачался), поддерживаются magnet-ссылки.
Как сделать программу портативной? (4.2.1+) — создать папку PROFILE рядом с qbittorrent.exe

Приложение для переноса раздач из uTorrent\Bittorrent, Deluge (Тема автора на оффоруме).

FEATURE: Allow to limit max memory working set size
BUGFIX: Fix UI crash when torrent is in a non-existent category
BUGFIX: Correctly handle changing of global save paths
BUGFIX: Disable performance alert
BUGFIX: Prevent loading resume data with inconsistent ID
BUGFIX: Properly handle metadata download for an existing torrent
BUGFIX: Prevent crash when open torrent destination folder
WINDOWS: NSIS: Update Spanish, Spanish International and French translations

Цитата:

Только там теперь появились 2 версии с QT6

С Qt5 тоже две версии.

Цитата:

В чем разница обычной с QT6 RC_1_2 x64? Что из них новее по составу? Релиз кандидат — новее или попредыдущее обычной QT6?

Я даже не хочу в это вникать сейчас — пусть сначала зарелизится и устаканится.

Цитата:

А что это такое. Спасибо.

Qt. Пожалуйста.

Цитата:

стабильное\супер-пупер новое и последнее

Получается, что обычный QT6 с новыми либами 2.0.x в отличие от QT6 RC_1_2?
А QT5 получается то же самое? Просто стабильнее\предыдущее?

2) qBittorrent 4.4.2 x64 ведёт себя чуть лучше (запоминает отключение предварительного резервирования места для файлов)

Вышел qBittorrent 4.5: новые функции, ускоренный запуск и улучшенный дизайн

Популярный кроссплатформенный клиент BitTorrent получил крупное обновление. Помимо расширения списка функций, разработчики улучшили пользовательский интерфейс приложения, а также окончательно отказались от устаревшей версии клиента для 32-разрядных систем.

Не самым важным, но одним из наиболее заметных изменений версии 4.5 стал модифицированный дизайн. Приложение получило диалоговые окна с изменяемым размером, новые цветовые темы и дополнительные палитры для тёмного и светлого интерфейса. Ещё одним крупным изменением стал отказ разработчиков от 32-разрядной версии клиента в связи с переходом на фреймворк Qt 6.

В числе функциональных нововведений отмечаются возможность разрешать пустые строки в многокомпонентном вводе данных формы, поддержка экспорта файлов .torrent, возможность для обработки событий перетаскивания и улучшенное отображение индикатора выполнения. Заявлена и более высокая скорость запуска приложения — правда, каких-либо цифр разработчики не приводят.

В новую версию была добавлена ​​навигация с помощью клавиатуры, возможность запуска внешней программы при добавлении торрента и настройки условия «остановка торрента». Кроме того, появились настройки ограничения рабочего набора в Linux, контекстное меню для фильтров статуса, функция автоматического изменения размера столбцов, возможность установить максимальное количество активных проверяемых торрентов и другие полезные нововведения.

Ознакомиться с полным списком изменений и скачать актуальную версию qBittorrent можно на официальном сайте разработчиков.

What do these highlighted versions mean ?

This is my understanding and I am totally open to being wrong. Just what I have gathered.

As another comment mentioned Qt is a GUI framework. It allows for customizing the UI through the a specific method. Qt is used very commonly on Linux so for porting some GUI customizations to Windows, having the matching Qt version helps. The top Windows download in the picture is Qt5, and the one below it is Qt6. Has no visual difference out of the box.

The versions with (RC 1_2) use the newest and last version of Qt, but they also use the libtorrent 1.2.x version instead of the current libtorrent 2.0. Both work, but some may still have a workflow that uses libtorrent 1.2.x or they may have some other compatibility issue. The first two listed downloads use the newer libtorrent 2.0. Libtorrent itself is basically the open source version of Bittorrent protocol.

You're wrong in your last paragraph and it contradicts with the shared screenshot and your second paragraph.

Install them and look at qBittorrent — Help — About — Software used.

It used to be mentioned in official News Page and download page for many months that qBittorrent with RC_1_2 are for those users who experience issues with default libtorrent v2.0 and Qt6 is something new that's experimental and unfortunately not compatible with Windows 7 and 8.

RC_1_2 means you get qBittorrent with libtorrent v1.2+ that has old cache settings and behaves same or better than old versions. Libtorrent v1.2 is something which is used to be default in previous qBittorrent versions before the official release of qBittorrent v4.4.0 that unfortunately at first only had installers for Windows users with only libtorrent v2.0. Since many users experienced new issues and believed that qBittorrent v4.4.0 is worse than v4.3.9 then afterwards additional official Windows installers were offered to make it easier for users to try if all newly discovered issues are fault of newer qBittorrent v4.4 code or is something caused by the usage of libtorrent v2.0 instead of more stable libtorrent v1.2.

Since v4.4+ installers with libtorrent v1.2 weren't available in the beginning, libtorrent v2.0 wasn't tested for various usage and many users didn't read the official page, misunderstood it or just are misleading others, which is why a lot of users unfortunately are still advising to use v4.3.9 instead of trying newer qBittorrent v4.4+ with libtorrent v1.2 if anyone is experiencing any speed, memory, crashes or any new issues with libtorrent v2.0 and qBittorrent v4.4+

RC means release candidate

Install them and look at qBittorrent — Help — About — Software used.

It used to be mentioned in official News Page and official Download page for many months that qBittorrent with RC_1_2 are for those users who experience issues with default libtorrent v2.0 and Qt6 is something new that's experimental and unfortunately not compatible with Windows 7 and 8.

RC_1_2 means you get qBittorrent with libtorrent v1.2+ that has old cache settings and behaves same or better than old versions. Libtorrent v1.2 is something which is used to be default in previous qBittorrent versions before the official release of qBittorrent v4.4.0 that unfortunately at first only had installers for Windows users with only libtorrent v2.0. Since many users experienced new issues and believed that qBittorrent v4.4.0 is worse than v4.3.9 then afterwards additional official Windows installers were offered to make it easier for users to try if all newly discovered issues are fault of newer qBittorrent v4.4 code or is something caused by the usage of libtorrent v2.0 instead of more stable libtorrent v1.2.

Since v4.4+ installers with libtorrent v1.2 weren't available in the beginning, libtorrent v2.0 wasn't tested for various usage and many users didn't read the official page, misunderstood it or just are misleading others, which is why a lot of users unfortunately are still advising to use v4.3.9 instead of trying newer qBittorrent v4.4+ with libtorrent v1.2 if anyone is experiencing any speed, memory, crashes or any new issues with libtorrent v2.0 and qBittorrent v4.4.x+

Now if curious what's Qt and libtorrent then use Google search. qBittorrent is just using various dependencies and their code to do different tasks and for average user going into details about them doesn't give much help.

Steps to Qt6 #14452

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

The text was updated successfully, but these errors were encountered:

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?

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.

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.

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.

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

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.

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!

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.

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.

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

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

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

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.

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

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.

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?

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.

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.

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.

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.

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)

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.

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

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.

Just as a «refresher»
#12970

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?

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.

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.