@sledgehammer999 you should read this => https://github.com/orgs/qbittorrent/teams/bug-handlers/discussions/5

Thankfully not having the virus (and I hope I stay that way).

I'm happy for you personally.

But I'm really sad about the current state of affairs in the project (and I'm not the only one who feels the same way). The time for change is critical. So you must either restructure the management/maintenance of the project, or explicitly declare that it is only your personal toy, so that no one else has false hopes.

Are there any commits that must be exempted?

I don't think it makes sense to skip any changes now.

In any case, a new release is long overdue.

Too much.

Should I, as usual, backport all new master commits into the v4_2_x branch?

Why v4.2.x? There are more then enough changes for v4.3!
Besides, you can simply create v4_3_x branch on top of current master, instead of doing this unnecessary work by "cherry-picking" out commits one by one.

I just finished looking at the commits from previous release until latest master. (commit titles and PR descritptions mostly)

Why v4.2.x? There are more then enough changes for v4.3!

Yeah. There is a ton of commits. And since libtorrent 1.1.x was dropped it surely warrants v4.3.x. (And v4.4.x for libtorrent 2.0.x and c++17!!!)
I'll create a new PR for the upcoming changelog, as soon as possible.

About project management: We'll discuss this after the weekend / upcoming release.

@sledgehammer999

Glad you are back and that everything is OK.

Should I, as usual, backport all new master commits into the v4_2_x branch? Are there any commits that must be exempted?

I am indifferent to the proposal of labeling the new version 4.3.x. It is up to you and others to decide.

All commits are good AFAIK. However, a lot of very important fixes have been merged to libtorrent as well, so it is important to use the latest possible RC_1_2 for this new release.

There have been a couple of commits already concerning BitTorrent V2 support. However, I would expect this release to be built with the latest libtorrent RC_1_2 as mentioned above, so most users won't see any of it in practice. Thus, I would put a note in the changelog explaining this, so that the users don't get false hopes when they read the BitTorrent V2-related entries.

I have made my local toolchain up-to-date. The backporting/changelog/minimal testing will take sometime. But I think this weekend is a feasible target depending on the size of the changes.

Can you please provide details about this? I assume you have the very latest MSVC 2019 and I _hope_ you're using vcpkg or similar for the dependencies - less chance of strange bugs due to slight discrepancies in the way everything is built and more reproducibility. You can checkout the new GitHub Actions CI for inspiration. Also please remember to use CMake for building this time around, it has become the new default buildsystem.

About project management: We'll discuss this after the weekend / upcoming release.

OK, but sooner rather than later please. And we must continue the discussion of automating the release process further, so that even packaging can be done automatically.

@sledgehammer999

Also, please clean up the PPA in the process. Ubuntu releases other than 18.04, 20.04 and 20.10 are EOL, so archives for builds targeting those versions should be removed ASAP.

so it is important to use the latest possible RC_1_2 for this new release.

This goes without saying.
Qt 15.1, openssl 1.1.1h, boost 1.74

RC_2_0 won't be used yet. Not without a a couple of official beta releases.

I assume you have the very latest MSVC 2019 and I hope you're using vcpkg

No, I am still staying with msvc2017 for this release. Last time I checked msvc2019 it produced very big .pdb file for qbt. I'll check again later but not for this release.
The rest of the dependencies are built the way I have always done things. More or less described here: https://github.com/qbittorrent/qBittorrent/wiki/Compiling-with-MSVC-2019-(static-linkage)

Also please remember to use CMake for building this time around, it has become the new default buildsystem.

Apparently I missed this in the git log. I am kinda bummed but I can't really object it since all others are feeling more comfortable with using cmake than autotools/qmake.
However, for the time being I'll continue to use autotools/qmake for the release. I don't have time to familiarize myself with cmake for the release.

I'll see what to do about the PPA, although they don't harm anyone.

@sledgehammer999 I know you don't want normal users commenting here, so apologies......I've been making windows builds here for the purpose of squashing issues/bugs etc.

I compile with MSVC 2019 & qBittorrent executables are usually around 27 MB & .pdb are 180 MB

Have you thought of using /pdbstripped?

I compile with MSVC 2019 & qBittorrent executables are usually around 27 MB & .pdb are 180 MB

Compare with msvc2017 and current master: 24.4MB exe and 98.1MB pdb. As I said the pdb is very big compared to msvc2017.

Also I don't think we want /pdbstripped. It will probably give less useful backtraces when the program crashes.

Also I don't think we want /pdbstripped. It will probably give less useful backtraces when the program crashes.

/PDBCompress?

@sledgehammer999

The automated CI builds, which use CMake + the latest MSVC 2019 + vcpkg (https://github.com/qbittorrent/qBittorrent/actions) are at 57 MiB (executable) + 122 MiB (pdb).

No, I am still staying with msvc2017 for this release. Last time I checked msvc2019 it produced very big .pdb file for qbt. I'll check again later but not for this release.

This is not a good reason IMO. MSVC 2019 contains many fixes. It's (the end of) 2020. No one cares about an extra \~50 MiB installation size (and if they do, too bad lol). We can figure it out later if something is bloating the pdb/executable, but for now everything works and an extra \~50 MiB is a tradeoff I'd make any day of the week for a much more recent toolchain.

Also I don't think we want /pdbstripped. It will probably give less useful backtraces when the program crashes.

:+1:, but this can be properly investigated in the future.

The rest of the dependencies are built the way I have always done things. More or less described here: https://github.com/qbittorrent/qBittorrent/wiki/Compiling-with-MSVC-2019-(static-linkage)

Apparently I missed this in the git log. I am kinda bummed but I can't really object it since all others are feeling more comfortable with using cmake than autotools/qmake.
However, for the time being I'll continue to use autotools/qmake for the release. I don't have time to familiarize myself with cmake for the release.

:-1:, this is not the way most people have been testing qBittorrent for the past months on Windows. Many people were using builds from my CI branch (CMake + vcpkg), and now the repo's own Actions section. I'd say it's highly likely we'll observe unexplained regressions just stemming from the differences in the build process if you do this.

@sledgehammer999 I don't want to add anymore "blockers" before the release, but at least I'd wait for this to land, since it is basically ready: https://github.com/qbittorrent/qBittorrent/pull/13499

The change in the default for async I/O threads will be beneficial for many users.

I don't want to diss msvc2019 but I think you are a bit over the top in considering everything brand new as better. It isn't always the case. And yes 50MB extra for a bt client is a big deal. It is unnecessary bloat without any measurable benefit (eg the program doesn't become 1.5x faster).

Lastly about build systems: If we see regressions just from the build system change then there is something seriously wrong with the code. Stuff shouldn't be so fragile.

13499 is out of scope since it is about a libtorrent 2.0.x option which isn't the default yet. Lastly the cut will be made in the weekend.

@sledgehammer999

I don't want to diss msvc2019 but I think you are a bit over the top in considering everything brand new as better. It isn't always the case.
And yes 50MB extra for a bt client is a big deal. It is unnecessary bloat without any measurable benefit (eg the program doesn't become 1.5x faster).

Please don't just dismiss my arguments as "new = better". And I think you are a bit "over the top" with sticking to a worse toolchain for 50 MiB. Of course you never (or very rarely) see a "1.5x" speed up from updating your toolchain. But that is an unrealistic bar to set. With a more recent toolchain there might not be "1.5x" speed up, but there are always small performance improvements, better language support, better code gen (sometimes leading to less bugs), ... There are plenty of resources online documenting the improvements in MSVC 2019.

Again, I agree that we should shave those extra 50 MiB off if at all possible, but my point is that if we can't do that in time for the next release (or ever!), _that's OK_. Also, there is no implication that this will keep happening with every release once again (I would also be annoyed in that case). This is very clearly a one-off issue. As a user, I wouldn't want to hear "here's your worse quality binary, but at least we saved you 50 MiB, bro". 50 MiB is a rounding error nowadays (for desktop programs, anyway; of course in the embedded world and such this is not the case). I'm sorry, but you are just wrong if you think otherwise.

Lastly about build systems: If we see regressions just from the build system change then there is something seriously wrong with the code. Stuff shouldn't be so fragile.

Not necessarily. Something can be seriously wrong with the build system itself. See the previous state of the CMake buildsystem, before my overhaul PR. Before that, building with CMake caused quite a few bugs. Some (sometimes serious!) problems really do stem from incorrect/bad build systems and build recipes. No matter how robust your code is, if you build it wrong, it will break, sometimes in very spectacular but hard to diagnose ways.

13499 is out of scope since it is about a libtorrent 2.0.x option which isn't the default yet. Lastly the cut will be made in the weekend.

Please see the rest of the discussion. That PR also actually changes the default number of async I/O threads, so that by default, at least 2 hashing threads are used when building against libtorrent 1.2.x, too. This results in a very significant performance boost for SSD users (more than 1.5x, actually, heh) while providing a very marginal gain for HDD users as well.

@sledgehammer999

Here's some help to get you started:

• the new tutorial for building with CMake statically on Windows: https://github.com/qbittorrent/qBittorrent/wiki/Compilation:-Windows-(MSVC-2019,-64-bit,-static-linkage)
• list of options + short CMake tutorial/intro: https://github.com/qbittorrent/qBittorrent/wiki/Compilation-with-CMake:-common-information

In case you are not using vcpkg, or if you are using vcpkg for some packages but not others, you just need to additionally pass the appropriate hints that tell CMake where to find the configuration files for the pacakges, like -DLibtorrentRasterbar_DIR=C:\path\to\libtorrent-install-dir\lib\cmake\LibtorrentRasterbar. If in doubt, you can simply run the configure until it succeeds, fixing each error message about each package one at a time as they pop up, since the error messages are helpful enough that you can always understand and figure out what you need to add next.

I am not going to argue further about compilers. I don't agree with you specifically for qbt. msvc2019 will become much more relevant for us once we switch to c++17. Lastly, for a bt client user all he cares is if the client can achieve top down/up speed. That's is the metric for "better" or "worse" quality binary. msvc2017 achieves that without extra bloat. --I hold my judgement till I redo my builds with msvc2019--

like -DLibtorrentRasterbar_DIR=C:\path\to\libtorrent-install-dir\lib\cmake\LibtorrentRasterbar

Does it make a difference how a package is build/installed? Currently I don't have cmake folder under lib for any of boost, libtorrent, openssl. Only for qt.
PS: boost and libtorrent are build using b2. Openssl using their configure script.

@sledgehammer999

The only requirement is that you build libtorrent with CMake, IIRC. All other packages either generate the required configuration files by default or are supported by CMake in some way:

• libtorrent has to be built with CMake in order for the appropriate files to be generated. This is specifically covered in the Wiki tutorial.
• CMake natively supports OpenSSL via a bundled find module: https://cmake.org/cmake/help/latest/module/FindOpenSSL.html#hints. You just need to set OPENSSL_ROOT_DIR. Example: -DOPENSSL_ROOT_DIR=C:\Qt\Tools\OpenSSL\Win_x64
• boost generates the required files by default. You just have to set Boost_DIR Example: -DBoost_DIR=C:\path\to\boost_1_73_0\stage\lib\cmake\Boost-1.73.0
• For zlib you have to pass some paths. Example: -DZLIB_INCLUDE_DIR=C:\path\to\zlib-1.2.11\build -DZLIB_LIBRARY=C:\path\to\zlib-1.2.11\build\libzlibstatic.a
• Qt generates the required files, I assume you already figured out the required configure time flag required to point to them.

Again, if you're missing any of these, CMake will tell you about it in the configure step, and will suggest exactly what it wants you to add.

I agree with sledgehammer999.
Smaller binary is always better. Specially given the track record of past releases.
Many still have a slow internet..also the website serving the binaries could be slow for some users based on location.
In such cases a small binary allows faster download. People may get discouraged to update if they suspect unnecessary bloatware.

it has become the new default buildsystem.

default buildsystem of what?

it has become the new default buildsystem.

default buildsystem of what?

he even declared qmake/autotools deprecated https://github.com/qbittorrent/qBittorrent/wiki

he even declared qmake/autotools deprecated https://github.com/qbittorrent/qBittorrent/wiki

This arbitrariness is starting to really infuriate!

it has become the new default buildsystem.
default buildsystem of what?

This arbitrariness is starting to really infuriate!

oh wow! So it isn't an actual decision! I don't feel bummed after all.

@FranciscoPombal
Please don't distract @sledgehammer999 with useless conversations about different build tools, build systems, etc. Let upcoming release be done in an usual way - it will be faster and more reliable. We need to have time to resolve organizational issues so that we can keep the project afloat, regardless of the fact that one of its members disappears for a long time.
It also makes no sense to discuss libtorrent-2.0 in the context of the upcoming release (and the entire upcoming branch), since we don't have support for it, and we can't even predict when it will be fully implemented.

It's (the end of) 2020. No one cares about an extra ~50 MiB installation size (and if they do, too bad lol).

My two main computers are 9 and 12 years old (although I have recently improved them by installing SSD as system disks). Many use even older hardware. It's not because we like it. We just don't have the financial/other capacity to update it every 2-3 years. If you are not able to understand us, it still does not give you the right to make fun of us.

P.S. However, even 10 years ago I would not have worried so much about these 50 megabytes.

@an0n666 @sledgehammer999 @glassez

I agree with sledgehammer999.
Smaller binary is always better. Specially given the track record of past releases.
Many still have a slow internet..also the website serving the binaries could be slow for some users based on location.
In such cases a small binary allows faster download. People may get discouraged to update if they suspect unnecessary bloatware.

Come on now, application download is a one time cost. Even at 10 Mb/s, an extra 50 MiB is just an extra 50 seconds. If these people are that bothered by that, they better fucking come here and help fix the issue themselves. Don't let yourself be pushed around by obsessive compulsive people who complain about 50 MiB. They want to switch back to uT 2.2.1 because of that? Fine. Even in Somalia you can get 10 Mb/s on average: https://www.speedtest.net/global-index, and I doubt a BitTorrent client is the main preoccupation of most native Somalis. The builds are served from both Fosshub and Sourceforge, which are unlikely to ever become the bottleneck unless Kim Kardashian told all her fans to download qBittorrent or something.

Also,

Smaller binary is always better. Specially given the track record of past releases.

Citation needed. Where is the correlation between "better track record", and "smaller binary size"? Better track record of what? Performance? Reliability?

default buildsystem of what?

he even declared qmake/autotools deprecated https://github.com/qbittorrent/qBittorrent/wiki

This arbitrariness is starting to really infuriate!

oh wow! So it isn't an actual decision! I don't feel bummed after all.

We did agree that the CMake build system was the future. It is a mistake to keep maintaining two build systems, as I've stated many times before. This is even mentioned in recent contributions: https://github.com/qbittorrent/qBittorrent/pull/13509#issuecomment-708072078

Speaking of bloatware: Look at the duplicate effort we have due to maintaining 2 build systems. Look at the several files of autotools bloat we have in the repo.

Please don't distract @sledgehammer999 with useless conversations about different build tools, build systems, etc. Let upcoming release be done in an usual way - it will be faster and more reliable.

Yet another attack on probably the most active member in this repository for the past several months, and who has made crucial contributions, especially in the field of build systems, tools, etc. The new builds and modifications to the build system _are_ more reliable. As I recall, there have even been cases of issues that disappeared simply by building with the new method. Thanks to my efforts, we can now get more reliable builds much faster to the hands of users. It is certainly NOT useless. I have plan to further improve this, up to the point of official release, but don't count on me if you keep disparaging my participation like that.

I'm not distracting him, I'm bringing him up to speed with important developments from the past months. The onus is on him to catch up.
Now that sledge has returned, I want to get the build out the door as much as anyone, but I want to do it _right_. sledge being back shouldn't mean we have to return to our old ways (even for this release feels like a compromise), it should mean we can evolve _faster_ to reach the place we want to be in.

We need to have time to resolve organizational issues so that we can keep the project afloat, regardless of the fact that one of its members disappears for a long time.

Part of the issue is relying on a single person to manually produce builds with an ageing and less maintainable build system, jumping through hoops just because of 50 MiB (which can be solved later), etc. Consider the fact that we are deviating from the toolchain we use in our CI just for this. Even if it isn't actually a big issue now, it is a bad principle and precedent.

It also makes no sense to discuss libtorrent-2.0 in the context of the upcoming release (and the entire upcoming branch), since we don't have support for it, and we can't even predict when it will be fully implemented.

We don't need to talk about libtorrent 2.0 at all. Just a small note explaining that support for V2 is still not present despite the fact that some mentions of V2 support will appear in the commit messages in the changelog. For example, 19d77b0881dc777b7930106869854067e5b2faba. (unless of course you don't cherry pick those commits for the 4.3.0 release, but that complicates things IMO).

My two main computers are 9 and 12 years old (although I have recently improved them by installing SSD as system disks). Many use even older hardware. It's not because we like it. We just don't have the financial/other capacity to update it every 2-3 years. If you are not able to understand us, it still does not give you the right to make fun of us.

P.S. However, even 10 years ago I would not have worried so much about these 50 megabytes.

Please point to where I "made fun of" low spec users. I too have a 12 year old C2D laptop that I installed an SSD on (the connection is only SATA II though!) that I still use frequently. I also don't own any machine with a processor made in the last 3 years, and I wish I could get an AMD Ryzen in the future. I certainly don't "upgrade every 2-3 years". I understand and agree with you. I just made fun of people who complain about 50 MiB on a desktop/laptop nowadays (read: last 15+ years), because those people deserve to be made fun of.

Yet another attack on probably the most active member in this repository for the past several months

Please stop looking for some hidden subtext in my comments. I just said what I said. I hope your reaction doesn't confuse anyone.

I'm not distracting him, I'm bringing him up to speed with important developments from the past months. The onus is on him to catch up.

Everything has its time and place.
Why press @sledgehammer999 here and now, if it can only lead to the fact that he will have no time neither to make the next release, nor to restructure the management/maintenance of the project before he disappears again, so that we will not be able to continue full-fledged work in his absence.

We don't need to talk about libtorrent 2.0 at all. Just a small note explaining that support for V2 is still not present despite the fact that some mentions of V2 support will appear in the commit messages in the changelog.

I have repeatedly mentioned that the change log should not blindly copy git history. You should keep in mind that:

1. some commits are part of a single fix/improvement/feature, so it makes sense to mention it in its entirety;
2. some commits fix intermediate errors that were not present in the previous release, so it makes no sense to mention them;
3. some commits are part of some unfinished work, so it makes no sense to mention them.

@sledgehammer999
Please be notified for issue #13519. I would suggest not including PR #11644 in the upcoming release unless someone found a reliable fix and is well tested.

EDIT: false alarm: https://github.com/qbittorrent/qBittorrent/issues/13519#issuecomment-710744534
EDIT(FranciscoPombal) not a false alarm: https://github.com/qbittorrent/qBittorrent/issues/13519#issuecomment-710911209

@sledgehammer999 @Chocobo1 @glassez

Sorry for the mass pinging, but this one seems fairly critical as well, and unfortunately a bit of a mess right now (I'm also confused at this point as to what the problem actually is): https://github.com/qbittorrent/qBittorrent/issues/13389. Maybe one of you can shed some new light on it?

One thing is for certain; I wouldn't want to risk breaking everyone's *arr setups with the first 4.3.x release.

this one seems fairly critical as well, and unfortunately a bit of a mess right now (I'm also confused at this point as to what the problem actually is): #13389. Maybe one of you can shed some new light on it?

One thing is for certain; I wouldn't want to risk breaking everyone's *arr setups with the first 4.3.x release.

Please don't start freaking out at the very end. What's the problem? (In addition to problems with understanding the application logic.) We didn't change the related code, did we? I certainly didn't read the entire thread. If there is clear evidence of a bug in the app, please point me to a specific comment.

@glassez

Please don't start freaking out at the very end. What's the problem? (In addition to problems with understanding the application logic.) We didn't change the related code, did we? I certainly didn't read the entire thread. If there is clear evidence of a bug in the app, please point me to a specific comment.

No one is freaking out, we just need to be aware of the potential consequences. The point is for someone else to read the thread carefully and with a clear head. Back when I tried to tackle it I couldn't be sure if it was a legit regression or a user misrepresentation of a recent change, or if the recent wording change exposed an unexpected defect or what. This is compounded by the fact that I've never actually used any *arr software, but I know that many people do. Regardless, here are the original reports in the *arr repos: https://github.com/Radarr/Radarr/issues/5032 https://github.com/Sonarr/Sonarr/issues/3968, if you want to take a look.

Hello guys,

I just noticed that someone mentioned FOSSHUB in a previous comment. I've read the thread and want to say this. Assuming qBittorrent will have around 50 MB, that makes no difference to us. The same with any traffic spike, someone mentioned Kim Kardashian. Please have her recommend qBittorrent; I am sure we will not go down. We can absorb that traffic. For example, whenever a new qBittorrent is released, we have seen thousands of update requests per second.

What I am trying to say is that you shouldn't worry about this.

Thank you!

my 1.5cents it does build and run nicer on msvc2019 for whatever reason
50mb of diskspace is absolutely nothing in 2020, if your system is THAT constrained then you are running a lighter client or qbt-cli anyway

never put off getting your project on the latest and greatest when it can be done without causing bugs the longer you wait the more you risk falling behind and being stuck on a dead unsupported compiler is never fun for anybody

I think sledge was referring to issues like these being opened even after only 12 MiB increase in the installer size.
https://github.com/qbittorrent/qBittorrent/issues/12247

So it’s not even 50 MiB but only 12 MiB that people are going to the length of creating an issue ticket.

@sledgehammer999 "IF" you are going to use Qt 5.15.0/5.15.1 in next release, take note of (Context menu closes after choosing one tag) #13492

Simply put I think if it's going to be labelled 4.3 nobody is going to complain about installer being larger, it would be expected surely! Keeping with antiquated toolchains honestly feels like a fitting representation of the release process of qBittorrent.

Excited to finally see this happen, I had almost given up hope of seeing something this year.

I think sledge was referring to issues like these being opened even after only 12 MiB increase in the installer size.

12247

>

So it’s not even 50 MiB but only 12 MiB that people are going to the length of creating an issue ticket.

So? The only appropriate response for such tickets is "whatever, man.". I don't understand the obsession with bending over backwards for these people. Like I said in https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment-708436739, we will of course always do our best to prevent such increases in size, but we shouldn't sacrifice anything else just for 50 MiB, and if some people are that bothered by that, they can come here and fix it themselves.

we shouldn't sacrifice anything else

I am sorry, but I really don't see what we sacrifice by not going to the latest and greatest(doubt) compiler. There is nothing tangible of going to the latest compiler. It's not as if msvc2017 is an ancient compiler.

@sledgehammer999

I am sorry, but I really don't see what we sacrifice by not going to the latest and greatest(doubt) compiler. There is nothing tangible of going to the latest compiler. It's not as if msvc2017 is an ancient compiler.

https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment-711123971

my 1.5cents it does build and run nicer on msvc2019 for whatever reason

As mentioned before, I recall other such accounts of this in the issue tracker or other communication channels. I am not making this up.

Regardless, one should always try to use the latest toolchain (within reason, but MSVC 2019 is mature at this point), unless there is a very good reason not to. Furthermore, the MSVC 2019 builds have been extensively battle-tested over the past few months, either provided by me, xavier2k6, or others, or now, more recently, with the official GitHub Actions workflow. 50 MiB is not a good reason, as many people are trying to tell you. Don't let yourself be bullied by those who obsess over 50 MiB!! I'll personally take care of those reports, you won't even have to see them.

Is upgrading to MSVC2019 something that takes a lot of time to do? It's just a case of when not if isn't it? So if not this release then surely the next, given releases are generally nearly months apart.

https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment-711123971 is only one subjective report which is most likely affected by using the latest libs and qbt code. Not because of compiler.

Is upgrading to MSVC2019 something that takes a lot of time to do? It's just a case of when not if isn't it? So if not this release then surely the next, given releases are generally nearly months apart.

reason is given here https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment-708055242

Don't let yourself be bullied by those who obsess over 50 MiB!!

I won't let myself be bullied by those who obsess with the "latest and greatest" either. And the difference is actually 68MB of extra storage (I did local static builds). msvc2017 just works! and doesn't require extra space.

13505 (comment) is only one subjective report which is most likely affected by using the latest libs and qbt code. Not because of compiler.

And your comments about MSVC 2019 not providing any benefits at all are also unsubstantiated claims.

I won't let myself be bullied by those who obsess with the "latest and greatest" either. And the difference is actually 68MB of extra storage (I did local static builds). msvc2017 just works! and doesn't require extra space.

Bad comeback. No one advocating for the latest toolchain is "bullying" you. Sticking to the latest toolchain (again, withing reason) is objectively the better policy, especially when the only argument against it is that it produces a bit larger binaries (we're not developing for some embedded platform). Furthermore, it is not good policy to make a release with a toolchain that's different from the one CI and most users and contributors have been using for the last _months_. And to top it all off, it is likely that there is a relatively simple fix for the binary bloat - ask your 50 MiB friends to invest their energy in finding the problem rather than just complaining about 50 MiB if it bothers them so much.

(msvc2017 =>msvc2019) can be discussed/argued/debated etc in another issue _WHEN_ it becomes neccessary

msvc2019 will become much more relevant for us once we switch to c++17.

It will also become more relevant in the move to Qt 6.0/6.1/6.2 when Qt require msvc2019 & drop (windows 7/8/8.1 & 32 bit support) (which is a long long way away yet from being implemented, I know)

Development hosts and targets in Qt 6.0

Qt 6.0 development hosts

Qt 6.0 development targets

Qt 6.1 development hosts

Qt 6.1 development targets

I am not going to argue further about compilers. I don't agree with you specifically for qbt. msvc2019 will become much more relevant for us once we switch to c++17.

reference: https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment-708094578

FOR NOW!, CAN WE ALL ONCE & FOR ALL PARK THIS HERE FOR ANOTHER TIME?

Let's get 4.2.x/4.3.x out the door!

(msvc2017 =>msvc2019) can be discussed/argued/debated etc in another issue WHEN it becomes neccessary

FOR NOW!, CAN WE ALL ONCE & FOR ALL PARK THIS HERE FOR ANOTHER TIME?

Let's get 4.2.x/4.3.x out the door!

Look, I want this over with as much as anyone else, but if nothing else, it is frankly irresponsible to change the toolchain at the last minute for the release when everybody else, including you, has been using and testing with MSVC 2019 for the last _months_. When seen from this lens, I believe it is very much "necessary" to use MSVC 2019 for this release.

Personally, I've got a lot of skin in this game: if anything goes wrong, it will be me dealing with the majority of bug reports of type "the nightly/CI build worked fine but the release doesn't" etc etc. And yes, I know I don't "have" to deal with it. But I don't want the project swamped with new issues after a release for a reason that can be avoided. It is already bad enough that the release won't be done with libraries compiled in the same or similar way as the CI.

It baffles me how all of this, including the time and effort I put into the project and managing the issue tracker is not more important than someone obsessing over 50 MiB. Who are these people, even? What have they done for the project?

@FranciscoPombal I won't have any further compiler discussion in here. My word is final. The releases will be made with msvc2017.

if I remember correctly only Qt 5.15 "officially" supports msvc2019. they didn't start running there ci on msvc2019 till Qt 5.15
and he can't release with qt 5.15 anyway because of bugs mentioned previously.

Look, I want this over with as much as anyone else, but if nothing else, it is frankly irresponsible to change the toolchain at the last minute for the release when everybody else, including you, has been using and testing with MSVC 2019 for the last months. When seen from this lens, I believe it is very much "necessary" to use MSVC 2019 for this release.

MSVC 2017 builds are battle-tested with whole 4.2.x release cycle and there is not much new in msvc 2019 anyway and msvc 2017 still has mainstream release cycle, I can't understand why you're so obsessed with "latest and greatest".

@xavier2k6

Besides, suppose we don't fix the extra 50 MiB "problem" before the next "big" release. Are we all going to have this same discussion then? Are we going to put off the upgrade to Qt 6 because of it? What is/isn't more important than 50 MiB? We're just sweeping the problem under the carpet, it's a bad precedent.

Hint, I can almost guarantee that, from the opinions I have seen from others over time, the upgrade to Qt6 will be put off for much longer than is reasonable, for all these 3 reasons, and possibly more, in no particular order: extra 50 MiBs installer size, keeping support for Windows 7 alive, keeping support for 32-bit builds alive.

@jagannatharjun Qt 5.15.1 builds fine with msvc2017. The only linked issues is about the context menu closing when selecting tags. IMO, that's not a blocker. Qt 5.15 brings much better HiDPI support though.

@FranciscoPombal I can understand where you are coming from & your work here is very much appreciated!

The points you make have relevance but unfortunately, I don't think the current time frame in getting the "new release" out allows for this discussion....(at this time)

I can't understand why you're so obsessed with "latest and greatest".

Objectively superior policies are not "obsessions". I guess you could say that I'm obsessed with not catering to other stupid obsessions. But do me a favor and stop projecting this on me, yes? It doesn't strengthen your point.

You guys are seriously considering keeping a reasonable pace of upgrades/modernization as an "obsession" and to not be more important than 50 MiB in the installer. Jesus fuck.

@jagannatharjun Qt 5.15.1 builds fine with msvc2017. The only linked issues is about the context menu closing when selecting tags. IMO, that's not a blocker. Qt 5.15 brings much better HiDPI support though.

I agree, the context menu tags bug is unfortunate, but the HiDPI bugs are much more serious and produce many more reports over time.

@FranciscoPombal I can understand where you are coming from & your work here is very much appreciated!

Nice joke.

The points you make have relevance but unfortunately, I don't think the current time frame in getting the "new release" out allows for this discussion....(at this time)

I see I can't do anything else. Oh well.

@FranciscoPombal I can understand where you are coming from & your work here is very much appreciated!

Nice joke.

@FranciscoPombal Seriously?? - This was not a joke & I was/am being personally sincere!!!

The points you make have relevance but unfortunately, I don't think the current time frame in getting the "new release" out allows for this discussion....(at this time)

I see I can't do anything else. Oh well.

Don't take this situation personally/to heart......ok
........take a breather
let part of your hard work in the project at least get to see the "mainstrem public" via the new release. (as currently it can only be seen by people like me who come here & participate/contribute/build etc

I have just pushed a staging_v4_3_x branch. It is basically master with an updated changelog.
Please take a look at Changelog and tell me if something is wrong or I missed something.
@glassez

1. Does #13234 have any user facing attributes? Something that should be in the changelog? eg "improve loading speed of sessions with hundreds of torrents".
2. What is the purpose of #13395. What does it do? Should I include something in the changelog?

In a bit I'll look at issues mentioned in this thread that might make some commits not included for release. I'll keep you informed.

@sledgehammer999

Also, please clean up the PPA in the process. Ubuntu releases other than 18.04, 20.04 and 20.10 are EOL, so archives for builds targeting those versions should be removed ASAP.

Ubuntu 14.04 and 16.04 are not EOL. Where did you get that list from?
https://wiki.ubuntu.com/Releases

@sledgehammer999 It seems you missed https://github.com/qbittorrent/qBittorrent/pull/13188 for changelog

also, can you add a note in the changelog that
"The previous theme bundles will not work properly with this release because of changes in the format of bundle files, Please contact the theme provider for a fix. One can read more about the new format here https://github.com/qbittorrent/qBittorrent/wiki/How-to-use-custom-UI-themes" or something like that.
Actually, this is because of https://github.com/qbittorrent/qBittorrent/pull/12755/files

I think it should be mentioned that support for RC1_1 libtorrent has been dropped.

Also if someone wants a faster tracker announce rate or is having a slower client exit(compared to 4.2.x) with this version then they may try increasing the "Max Concurrent HTTP announce" limit from advanced settings.

Does #13234 have any user facing attributes? Something that should be in the changelog? eg "improve loading speed of sessions with hundreds of torrents".

I'm sorry, I don't remember everything... it was mostly internal improvement. Maybe the next part of the PR description fits "user facing attributes":

It allows to correctly save resume data under some circumstances, e.g. in "missing files" state (although we tried to prevent this from being done earlier, the user could actually do it when, for example, changing some property of such a torrent).

What is the purpose of #13395. What does it do? Should I include something in the changelog?

https://github.com/qbittorrent/qBittorrent/pull/13395#issuecomment-710787904

I think it should be mentioned that support for RC1_1 libtorrent has been dropped

👍

FEATURE: Add support for creating v2 torrents(requires libtorrent 2.0.x) (Chocobo1)

Damn it! Does qBittorrent already support libtorrent-2.0? Why mention it like it is? We did already talk about it.

also, can you add a note in the changelog that
"The previous theme bundles will not work properly with this release because of changes in the format of bundle files, Please contact the theme provider for a fix. One can read more about the new format here https://github.com/qbittorrent/qBittorrent/wiki/How-to-use-custom-UI-themes" or something like that.
Actually, this is because of https://github.com/qbittorrent/qBittorrent/pull/12755/files

I think I'll add this to the "news" section of the website. Outside of the changes, in the introductory text.

I think it should be mentioned that support for RC1_1 libtorrent has been dropped.

OK.

Also if someone wants a faster tracker announce rate or is having a slower client exit(compared to 4.2.x) with this version then they may try increasing the "Max Concurrent HTTP announce" limit from advanced settings.

Should this be mentioned in the changelog as an item?

Damn it! Does qBittorrent already support libtorrent-2.0? Why mention it like it is? We did already talk about it.

Then I will move this item under v4.4.0 release entry (not part of v4.3.0 changelog). Unless official libtorrent-2.0 support is introduced earlier. Is that satisfactory?

Here is the updated changelog: https://github.com/qbittorrent/qBittorrent/commit/0302e8abbc545d13b7be51e011d2795a9bb3ea73

Should this be mentioned in the changelog as an item?

I think better if posted as news. As users with thousands of torrents/lots of trackers per torrent may notice the slow announcing behaviour.

Updated again: https://github.com/qbittorrent/qBittorrent/commit/727dec97540091f891991113299fa38468e13885

Announcement: A very small delay should be expected. I have to do a partial toolchain recompile because of a security issue I was informed via email. The details will be made available a few days after release. IMO, the severity is probably minor because the exploit requires someone malicious having local access or already running a malicious application on your system. In both cases you are already screwed even without qbt's security issue.

Ubuntu 14.04 and 16.04 are not EOL. Where did you get that list from?

Probably wrong wording. It is EOL for us because their Qt version is less than our minimum requirement.

OK. I think everything is set now, and I am preparing builds. The v4_3_x branch will be pushed alongside with the builds.

@sledgehammer999 Sorry for the late comment, but please remember to mention (in the news section of the website) that there have been many libtorrent fixes since the last release that are present in this one, including for known memory leaks, speed issues due to faulty cache settings logic on Windows, etc. You can take a look at libtorrent's 1.2.6-1.2.11 (1.2.11 is still not officially released but has a few changelog entries already) for inspiration and pick out the most relevant entries.

Out of curiosity, which libtorrent commit will be used?

OK, and latest git commit as always.

@rrrevin

Ubuntu 14.04 and 16.04 are not EOL. Where did you get that list from?
https://wiki.ubuntu.com/Releases

Probably wrong wording. It is EOL for us because their Qt version is less than our minimum requirement.

Well, I really meant "End of Standard Support" I guess, which is really what matters anyway. Beyond that, only paying enterprises get support. 16.04 is technically not even at "End of Standard Support" yet, but it is very close. And regardless, OOTB support for it was dropped like 2 years ago or so due to qBittorrent bumping the minimum required Qt version to 5.9.

@sledgehammer999 One more little thing: consider mentioning the known tag context menu minor regression in the news: https://github.com/qbittorrent/qBittorrent/issues/13492.

@sledgehammer999 You did not credit many of my PRs in the changelog... https://github.com/qbittorrent/qBittorrent/pulls?q=is%3Apr+author%3AFranciscoPombal+is%3Aclosed+milestone%3A4.3.0

@FranciscoPombal I combined all your CMake PRs into one entry. Your internal code cleanup PRs can't be mentioned in the Changelog. It should contain user facing fixes. Same with the many PRs of @Chocobo1
If I missed something specific, please mention it below. I'll wait a few moments, since I still do admininstrative task behind the scenes.

@sledgehammer999

It should contain user facing fixes.

OK, so:

• --> https://github.com/qbittorrent/qBittorrent/pull/13042 is user facing, since it fixes an announce bug in the embedded tracker. <--

• https://github.com/qbittorrent/qBittorrent/pull/12086, https://github.com/qbittorrent/qBittorrent/pull/13109, and https://github.com/qbittorrent/qBittorrent/pull/13439 are non user facing cleanups, so I guess that's fine.

• https://github.com/qbittorrent/qBittorrent/pull/13288 is kind of user-facing, I guess? Now users can download experimental builds from CI, is that considered user-facing?

• The remaining are either already credited, related to the CMake improvements (already credited as well) or related to https://github.com/qbittorrent/qBittorrent/pull/13288.

/offtopic (for another time) - perhaps the non-user facing cleanups should be included in "OTHER" or perhaps a new "CODE HEALTH" section? Users like to see that kind of stuff in the changelog.

--> #13042 is user facing, since it fixes an announce bug in the embedded tracker. <--

OK, sorry. It wasn't clear from the commit title. Can you suggest an appropriate changelog entry (for users reading it)?

The CI changes are usually irrelevant to releases.

/offtopic (for another time) - perhaps the non-user facing cleanups should be included in "OTHER" or perhaps a new "CODE HEALTH" section? Users like to see that kind of stuff in the changelog.

Hmm, I'll add an OTHER entry for code cleanups crediting both you and @Chocobo1

13288 is kind of user-facing, I guess? Now users can download experimental builds from CI, is that considered user-facing?

IMO, such thing can be mentioned in News instead (outside of Change log).

IMO, such thing can be mentioned in News instead (outside of Change log).

I could somehow cram a "nightlies" link in the downloads page...

~@glassez~ @sledgehammer999

IMO, such thing can be mentioned in News instead (outside of Change log).

I could somehow cram a "nightlies" link in the downloads page...

Just mention the CI stuff in the news, I would be hesitant in linking the "nightly" downloads page to a wider audience before we have git-based versioning in the executables. Otherwise all users will report all different nightly versions as "4.x.xalpha1", leading to confusion.

git-based versioning in the executables. Otherwise all users will report all different nightly versions as "4.x.xalpha1", leading to confusion.

Yeah, that's a correct remark.

@sledgehammer999

Can you suggest an appropriate changelog entry (for users reading it)?

"Fixed broken announce logic in embedded tracker causing failures in some cases."

CI builds could be used for malicious purposes as well. By creating malicious PR and later distributing links.
I would recommend not to link such a thing on the website.

@an0n666

CI builds could be used for malicious purposes as well. By creating malicious PR and later distributing links.
I would recommend not to link such a thing on the website.

This is also a good point. I guess I'd better start working on the workflow specifically for nightly builds that only builds from master that I've talked about before. Then we'll be able to link to nightly builds without fear of such a thing happening.

The release is made.
PPA will be cleaned up tomorrow.
Security issue details in a few days.
Organizational changes plan in a few days.

And as always a thank you to everyone for their contributions in this release cycle.