Bump minimum dependency versions

[FranciscoPombal]

It doesn't make sense to allow anything lower (our floor at the moment is what the Ubuntu 18.04 repository has).

Also,

Closes #13510

[zywo]

@FranciscoPombal that doesn't solve #13510

[FranciscoPombal]

@FranciscoPombal that doesn't solve #13510

I'll try harder to figure out the true cause then, and adjust this PR accordingly.

[FranciscoPombal]

This can be merged right away, but the libtorrent change will only have a real effect once arvidn/libtorrent#5221 is merged to the relevant branches.

[glassez]

This can be merged right away

Don't forget to apply the same changes to automake files.

[FranciscoPombal]

Big oof, I just realized version ranges are only available in CMake >= 3.19... they already updated the docs pages with the 3.19 RC, but I thought I was looking at some earlier version.

So I guess the ranges will have to wait, but that's not too bad. The main purpose of this PR is simply about raising minimum versions anyway.

[FranciscoPombal]

@glassez

Don't forget to apply the same changes to automake files.

Done. Christ, what a shitty build system. Such a noisy diff because of it. Also it forced me to search through the files to find all instances where versions should be changed... hope I didn't miss any.

[glassez]

Personally, I don't mind these increases. But maybe some of this is still unavailable on some systems? Although both boost and zlib are quite old. What about OpenSSL?

[Chocobo1]

Personally, I don't mind these increases.

Just curious, why? just because they are ancient?
We don't deny using newer versions (when necessary and they are widely available) but only when it happens then the version bumps will follow (i.e. the version numbers objectively reflect the requirement of code/libs, not some subjective choice), isn't that the case?

[glassez]

I don't think we should raise the requirements just because the previous versions are very old. But in fact (if I'm not mistaken), none of the active developers/testers of the project use such old versions (even close to them), we don't even care about the project being built with them (otherwise we would have to have CI configuration with the minimum supported versions). What is the point of us claiming that they are still supported? What if someone really hopes for it, and gets some errors? Do you really want to be responsible for supporting this junk?
I don't insist on raising them, of course. It may not have any problems. We can just wait for some problem to manifest itself in order to increase the requirements for the corresponding library.

[Chocobo1]

We can just wait for some problem to manifest itself in order to increase the requirements for the corresponding library.

I agree, at least that would fix a real problem (not hypothetical ones) and I think this falls into the "necessary" case in my previous reply.
So until it happens I wouldn't touch the numbers.

[FranciscoPombal]

@Chocobo1 @glassez

We can just wait for some problem to manifest itself in order to increase the requirements for the corresponding library.

I agree, at least that would fix a real problem (not hypothetical ones) and I think this falls into the "necessary" case in my previous reply.
So until it happens I wouldn't touch the numbers.

These newer versions are already widely available in all platforms. The oldest platform we support in practice is Ubuntu 18.04 due to the Qt 5.9 requirement. Theses version bumps reflect dependency versions available at least in that system.

Personally, I don't want to waste time with Windows/macOS users who report bugs with a self-compiled version that uses Boost 1.40 and/or OpenSSL 1.0, for instance. It is very likely that there will be some bug due to asio or something that was fixed in later versions. Or maybe some HTTPS tracker announces will fail due to the tracker using TLS 1.3 and them using OpenSSL 1.0. So we should bump the versions to prevent these kinds of problems and reports.

We are a small team, and can't afford to support such a wide spectrum of stuff. Of course, our CI should test the minimum versions also on Windows/macOS - this is something that, as discussed previously, should be addressed in the future.(*)

But CI only gets you so far. If someone needs to investigate a bug report more thoroughly from someone that compiled with Boost 1.40, OpenSSL 1.0 and zlib 1.2.5.2, are you going to bother installing all those crappy old versions? Or are you going to tell the user to try to reproduce the problem with a more recent stack? In either case, we would have saved everyone's time by just requiring newer versions in the first place. It is misleading to pretend that compiling with any of these very old versions of the dependencies will lead to any kind of good result, otherwise, we would be doing it ourselves.
IMO, dependency version support shouldn't be only about "the project technically compiles with versions this old". It must also be about what's convenient to us. So I disagree with waiting until the last possible moment to bump, I think we should be proactive.

I agree that bumping between patch versions would have been a not so great choice. But we are on the verge of a major (in terms of size) release, which is also a new series - 4.3.x. It's not a bad time to bump the requirements. We already did so for libtorrent, why not the rest?

(*)Windows/macOS may be exceptions to this... As you know, we are always racing to support newer Qt versions in these platforms due to the very important high DPI and other types of fixes that are only available in newer versions. In practice, it is very undesirable for anyone to compile with Qt 5.9 on Windows 10, for instance. Sometimes I really wonder if we should have split Qt requirements for Linux and Windows/macOS. I wouldn't like that, but it is something to consider.

[glassez]

We are a small team, and can't afford to support such a wide spectrum of stuff.
If someone needs to investigate a bug report more thoroughly from someone that compiled with Boost 1.40, OpenSSL 1.0 and zlib 1.2.5.2, are you going to bother installing all those crappy old versions? Or are you going to tell the user to try to reproduce the problem with a more recent stack? In either case, we would have saved everyone's time by just requiring newer versions in the first place.

This coincides with my reasons for not objecting to raising the minimum version requirements. But if someone from our small team has the desire to mess with it and believes that the game is worth the candle, then let them do it. I don't have the ability to catch errors that occur in builds other than my own.
Another reason is our previous experience. I have often seen a situation where we even delayed a release while waiting for a new version of libtorrent that fixed some bug or made important improvements, but we still continued to support a bunch of previous versions. The question is why, if these latest changes are so important to us?

[jagannatharjun]

Another reason is our previous experience. I have often seen a situation where we even delayed a release while waiting for a new version of libtorrent that fixed some bug or made important improvements, but we still continued to support a bunch of previous versions. The question is why, if these latest changes are so important to us?

regular versions bump on libtorrent is kinda ok, but I really don't like to update zlib or openssl or boost, these are used in my other projects and I really don't want to break those for no particular reason. I will say let someone open some can of worms and if nothing else can be done then we can drop the support for that particular problem.

[glassez]

By the way, as for the Boost... It doesn't seem to be a direct dependency, does it? Why not just reflect the corresponding requirements of libtorrent?

[FranciscoPombal]

@glassez

But if someone from our small team has the desire to mess with it and believes that the game is worth the candle, then let them do it.

Someone on this team is actively testing with such older versions? Can you name one such person that has been doing this, or is doing this right now, or will do this in the future?

I don't have the ability to catch errors that occur in builds other than my own.

Same. Sometimes a may go a bit out of my way for a slightly different setup, but not something totally different and outdated (like OpenSSL 1.0). Let's not forget that in some cases, like OpenSSL 1.0, it is even no longer supported upstream.

Another reason is our previous experience. I have often seen a situation where we even delayed a release while waiting for a new version of libtorrent that fixed some bug or made important improvements, but we still continued to support a bunch of previous versions. The question is why, if these latest changes are so important to us?

A good point, and I agree with it. We need to be less fearful of bumping the minimum required versions for this reason. Early versions of libtorrent 1.2.x have too many very prominent bugs to be used with qBittorrent. Would you recommend anyone building qBittorrent on any platform with libtorrent 1.2.2, for instance? With such a version, on Windows, they will suffer from the auto cache bug, then there is also the tracker announce queue bug leading to memory leaks, etc, etc, etc (just look at the libtorrent changelog). No one in their right mind is compiling qBittorrent from source with libtorrent 1.2.x releases older than the latest RC_1_2 or 1.2.10, despite the fact that we technically allow >= 1.2.0. They would produce unnecessarily buggy builds, basically unusable.

@jagannatharjun

regular versions bump on libtorrent is kinda ok, but I really don't like to update zlib or openssl or boost, these are used in my other projects and I really don't want to break those for no particular reason.

If your other projects have problems with building with, say, non-EOL versions of OpenSSL, more than likely you've got bigger problems and are accruing severe technical debt. Assuming of course, these are not "dead" projects that you want to keep in a certain state. But in either case, you should consider somehow better isolating your build environments, honestly.

I will say let someone open some can of worms and if nothing else can be done then we can drop the support for that particular problem.

I already explained why I don't think being so passive is a good idea. It's a waste of everyone's time.

Me and others (like @xavier2k6) have been building with bleeding edge versions for months. On my part, I recall having used Boost 1.71 through 1.74 so far (both Linux and Windows), and I also went through a few OpenSSL versions. Been using zlib 1.2.11 since I remember. Even Qt >= 5.15 doesn't support anything older than OpenSSL 1.1.1. We must keep up.

[FranciscoPombal]

By the way, as for the Boost... It doesn't seem to be a direct dependency, does it? Why not just reflect the corresponding requirements of libtorrent?

It's a direct dependency at least due to the circular buffer, right?

[glassez]

By the way, as for the Boost... It doesn't seem to be a direct dependency, does it? Why not just reflect the corresponding requirements of libtorrent?

It's a direct dependency at least due to the circular buffer, right?

Oh, that's right.

[glassez]

But if someone from our small team has the desire to mess with it and believes that the game is worth the candle, then let them do it.

Someone on this team is actively testing with such older versions? Can you name one such person that has been doing this, or is doing this right now, or will do this in the future?

I only referred to a previous comment of @Chocobo1 where he called it a good idea to wait for one of these dependencies to cause an error in order to increase the requirements for the corresponding library. I assume that he is willing to handle such problems, trying to figure out exactly where they come from (from which libraries and which versions).

[FranciscoPombal]

@glassez

I only referred to a previous comment of @Chocobo1 where he called it a good idea to wait for one of these dependencies to cause an error in order to increase the requirements for the corresponding library.

Well, we both (#13511 (comment)) agree that this approach is too passive. The only permissible scenario where it would be acceptable would be if someone would be willing to invest the time and effort to play with such old stacks. Which brings us to...

I assume that he is willing to handle such problems, trying to figure out exactly where they come from (from which libraries and which versions).

I can't speak for them, but is this really the case? @Chocobo1 are you actually willing to do this? Are you/Will you become the "designated solver of bug reports using very old dependency versions"?

Not to re-ignite this other debate, but some food for thought: the same reasoning applied here to tighten up version requirements also applies to OS support. **cough** Windows 7 support **cough**. @Chocobo1 do you have a Windows 7 VM where you test qBittorrent when a bug report about it comes in?

I only ask these questions because I have not seen this happen. But if there is a new commitment for the future, I can understand. Otherwise, it's a waste of time for everyone else.

[glassez]

the same reasoning applied here to tighten up version requirements also applies to OS support.

I do not think so. At least, if we are talking about Windows. Many programs perfectly support different versions of it, including quite old ones, without any tedious worries. If the program does not directly use some low-level API, then there should be no problems. Quite a large number of people still use Windows 7 (and I have serious assumptions that a lot of our users do too).

[xavier2k6]

IF minimum versions are going to be raised........I'd say for now, keep to these guidelines for libtorrent

EDIT: 15.Dec.2020 - libtorrent info links modified.

RC_1_1

You'll need at least version 1.49 of the boost library in order to build libtorrent.

Boost version 1.49 required

RC_1_2

You'll need at least version 1.58 of the boost library in order to build libtorrent.

Boost version 1.58 required

RC_2_0

You'll need at least version 1.66 of the boost library in order to build libtorrent.

Boost version 1.66 required

Although - just as an example:
Boost 1.73, more specifically asio 1.16.1 fixed one issue #11039 & may have fixed another #8740

BTW Just as a point of note, there are patches available for Boost

[FranciscoPombal]

@glassez

I do not think so. At least, if we are talking about Windows. Many programs perfectly support different versions of it, including quite old ones, without any tedious worries. If the program does not directly use some low-level API, then there should be no problems.

I understand your point about low-level APIs. However, nobody on the team uses Windows 7. There may be legitimate-looking reports that are in fact specific issues to Windows 7. Thus, again, for the same reasons as above, this is a waste of time (especially for people like me who are on top of the issue tracker all the time).

Besides, as you might recall, we are already accruing technical debt due to keeping Windows 7 support - there are problems compiling with modern MinGW versions because of it.

"just because it still technically compiles and appears to run fine, doesn't mean we are obliged to support it officially".

Quite a large number of people still use Windows 7 (and I have serious assumptions that a lot of our users do too).

I have serious doubts about that. But that doesn't matter. If they are running Windows 7 still, they shouldn't, and we shouldn't be complicit in enabling that. It's insecure.

Contrary to what you may believe, the vast majority of the most vocal people who still use Windows 7 today do not do so by true necessity, but due to a toxic mix of laziness and "beginner-expert" tech illiteracy. These are the same kind of folks that will try to "debloat" Windows 10 and use stuff like "Windows 10 Ameliorated" (genius idea to trust an OS ISO from some rando online) instead of the real solution, which is moving to Linux.

Would there be backlash from this vocal segment of the userbase which would be unpleasant to deal with? Probably. But fuck them, if they don't want to listen to reason. We're not here to indulge their bad habits.

Now the economic argument: Windows 10 is free nowadays. You only lose out on minor customization/"Microsoft account" stuff if you don't pay for a license. Not to mentioned that the "accessibility upgrade loophole" was never closed, so it is still possible to get a legitimate license that way, even if starting from an illegitimate copy of Windows 7/8.1.

If these people are using computers so old they can't even run Windows 10 reasonably, I doubt they're doing anything on a regular basis for which there isn't an adequate Linux replacement already, or for which WINE can't do a good job of running. CAD software, Photoshop et. al. is the kind of software that typically either doesn't run adequately in WINE or for which there isn't an adequate replacement, but are people running that kind of software in computers that can't even run Windows 10 properly?

I would be satisfied with just releasing the next release as the last one to support Windows 7 (even though I would have preferred for 4.2.5 to have fulfilled that role). I think what amounts to basically one extra year of support so far from our part is more than reasonable. Now it's time to move on.

[xavier2k6]

Again, IF minimum versions are going to be raised:

Should Qt be raised?

Qt 5.9 LTS => Qt 5.12 LTS

I very rarely use linux & don't use macOS so I don't know if there's a "cross-platform" reason or whatever to keep it at Qt 5.9 LTS or whether the reason was to wait for the next LTS version before moving to it.....if that was the case then i don't see the reason not to go to Qt 5.12 LTS as minimum.

[FranciscoPombal]

Again, IF minimum versions are going to be raised:

Should Qt be raised?

Qt 5.9 LTS => Qt 5.12 LTS

I very rarely use linux & don't use macOS so I don't know if there's a "cross-platform" reason or whatever to keep it at Qt 5.9 LTS or whether the reason was to wait for the next LTS version before moving to it.....if that was the case then i don't see the reason not to go to Qt 5.12 LTS as minimum.

I don't think so, because that means dropping out-of-the-box support for Ubuntu 18.04, which is still a well-supported release that many Linux users still use (including me). However, in practice, as mentioned above, no one is compiling with such old Qt versions on Windows/macOS. An (ugly) solution to that problem is having split version requirements for Qt depending on the OS as I mentioned at the bottom of #13511 (comment). I think 18.04 support should be maintained at least until 20.04.2 or 20.04.3 are released. Either way, in case anyone is thinking about this, it would be extremely idiotic and inconsistent to do something like dropping support for 18.04 before Windows 7.

[glassez]

I rolled up the changes from #13783 into this one

I don't like the way you did it.
First, #13783 is something more than just increasing the supported version number (than this PR was originally). It actually removes support for older versions from the code. So it's incorrect to just squash it here. At least it should be separate (original) commit.
Second, it is illogical to insert approved changes (#13783) as part of the still (at least formally) not approved ones, thereby delaying the merging of the former.

[xavier2k6]

set(minBoostVersion 1.65)

Shouldn't that be minBoostVersion1.66 so that libtorrent 2.x can be built without issues at compile time etc as per #13511 (comment) otherwise this will have to be bumped again via another PR.

EDIT: Just in case this was previously missed!

Doesn't Ubuntu 18.04 come with Qt 5.9.5? so that could potentially be raised from 5.9.0 to become the minimum supported version?

ref: #13511 (comment)

[FranciscoPombal]

@glassez

I don't like the way you did it.
First, #13783 is something more than just increasing the supported version number (than this PR was originally). It actually removes support for older versions from the code. So it's incorrect to just squash it here.

"Bump minimum dependency versions" implies removing support in the code, no? I was going to make these changes anyway as well, I was just waiting on vcpkg.

At least it should be separate (original) commit.

OK, that's not a problem.

Second, it is illogical to insert approved changes (#13783) as part of the still (at least formally) not approved ones, thereby delaying the merging of the former.

What exactly is not approved about this? My reading of the these latest comments (#13511 (comment) and #13511 (comment)) is that there was consensus with the changes thus far.

@xavier2k6

Doesn't Ubuntu 18.04 come with Qt 5.9.5? so that could potentially be raised from 5.9.0 to become the minimum supported version?

OK.

Shouldn't that be minBoostVersion1.66 so that libtorrent 2.x can be built without issues at compile time etc as per #13511 (comment) otherwise this will have to be bumped again via another PR.

That would imply dropping support for Ubuntu 18.04, which I don't think anyone wants right now. We could look into adding some logic to the build system for requiring a different minimum boost version based on the libtorrent version used, or OS (since you mentioned in a previous comment that boost >= 1.73 fixes some issues, and it would be possible to require that for Windows/macOS).

[glassez]

"Bump minimum dependency versions" implies removing support in the code, no?

At least it should do.

I was going to make these changes anyway as well, I was just waiting on vcpkg.

Unfortunately, you did not give any notice of this intention. What's more, it looks like you didn't even intend to actually do it. You explicitly declared this PR ready to merge without having these changes: #13511 (comment).

Second, it is illogical to insert approved changes (#13783) as part of the still (at least formally) not approved ones, thereby delaying the merging of the former.

What exactly is not approved about this?

What does it matter? There is PR that is already approved, so you just need to click on the "Merge" button. Why should we delay this just so that it becomes part of another PR? What's the point? It doesn't exist for me. Even if, say, the raise of other versions is approved after only a couple of hours, we will simply merge it after.

[xavier2k6]

That would imply dropping support for Ubuntu 18.04

Why is that? (I haven't looked in to it myself)

We could look into adding some logic to the build system for requiring a different minimum boost version based on the libtorrent version used

Why not set one & forget it - use libtorrent 2.x as the base (This way we know that 1.2.x/2.x will work if they have same min version)?!

or OS (since you mentioned in a previous comment that boost >= 1.73 fixes some issues, and it would be possible to require that for Windows/macOS).

Is there OS limitations for Boost versions??

Could also make the same point about raising libtorrent limits to as of now 1.2.11 that we know fix issues as for raising >= boost 1.73 but that's probably for another time?? can stay with libtorrent guidelines for now........

Unless it merits being discussed further before merging.

[FranciscoPombal]

@glassez

Unfortunately, you did not give any notice of this intention. What's more, it looks like you didn't even intend to actually do it. You explicitly declared this PR ready to merge without having these changes: #13511 (comment).

That comment was written long ago, when there was no expectation of the libtorrent release being ready soon, so at the time, I thought that we might as well merge what was ready. After 1.2.11 was released, I thought it was understood that this PR could be updated to reflect that (it is my interpretation of something you said yourself: #13511 (comment)).

What does it matter? There is PR that is already approved, so you just need to click on the "Merge" button. Why should we delay this just so that it becomes part of another PR? What's the point? It doesn't exist for me. Even if, say, the raise of other versions is approved after only a couple of hours, we will simply merge it after.

My point is that these changes are approved (just no "formally", with "Approve" button, but given @Chocobo1's last comments, I think the intention is clear), a fact that so far you have not disputed, contrary to what you said:

Second, it is illogical to insert approved changes (#13783) as part of the still (at least formally) not approved ones,

If the changes in #13783 are also approved, then what's the point of splitting the work? If you have any further requested changes, please post them here.

btw, I have reported the vcpkg build failure: microsoft/vcpkg#14941

[FranciscoPombal]

@xavier2k6

Why is that? (I haven't looked in to it myself)

Ubuntu 18.04 does not natively support anything newer than 1.65.x: https://packages.ubuntu.com/bionic/libboost-all-dev

Why not set one & forget it - use libtorrent 2.x as the base (This way we know that 1.2.x/2.x will work if they have same min version)?!

Is there OS limitations for Boost versions??

Could also make the same point about raising libtorrent limits to as of now 1.2.11 that we know fix issues as for raising >= boost 1.73 but that's probably for another time?? can stay with libtorrent guidelines for now........

Unless it merits being discussed further before merging.

If we wish to easily support widely used Linux distributions with "LTS" releases such Ubuntu, Debian, and derivatives, which are the most widely used ones, we must stick to the Boost version available in their repositories. Same reasoning for Qt, and same for OpenSSL and zlib (though in the case of these latter 2 dependencies, the versions available in the repositories of the "LTS" distros that we care about are also the very latest ones).

[FranciscoPombal]

Original CI failure has been solved, but there is another expected failure, from a problem that I've also already reported here: microsoft/vcpkg#14943.

[FranciscoPombal]

@glassez @Chocobo1

CI should be fixed now.

EDIT: as expected, CI passed now.

[glassez]

Approved. I don't want to stick around any longer.

[zero77]

Don't know if it helps but, the following source is good for tracking supported builds across multiple distros.

https://repology.org/project/

Using qbittorrent as an example:
https://repology.org/project/qbittorrent/badges

[xavier2k6]

With Ubuntu 18.04 now dropped, we can bump Boost dependency to 1.66 as per #13511 (comment) to be inline with ongoing libtorrent 2.x implementation