Qbittorrent: Release plan for 4.2.0 final release

[sledgehammer999]

My current plan is simple. I am guessing that the current master code is pretty stable.
Today I released a 2nd alpha. I plan to release another beta in about ~2weeks which will be based on libtorrent 1.2.x this time. If that proves stable too (no serious bugs reported), I plan to release 4.2.0 ~2 weeks after the latest beta.

Any thoughts? I don't suppose there is something I should wait for to be implemented for v4.2.0, right?

-- please only people involved with the development should comment in this bug

[jagannatharjun]

what about this - #10948?

[Chocobo1]

So far there is one known issue on master (minor, but might be annoying to some): #11233

[djtj85]

new 4.2.0 beta will use libtorrent 1.2.2?

i am using the 4.2.0 alpha since it released and I didn't find any bugs
my PC --> i7-4790K + 16GB DDR3 + 128GB SSD + 500GB SSD + 4x1TB WD Blue HDD
windows 10 pro x64 1903
1000/300 FTTB internet and daily traffic : 700-800GB down / 1,1 - 1,5TB up with 1300-1500 torrent
so I am waiting the new beta

[Chaython]

is there a full changelog?

[thalieht]

There is also #11076

is there a full changelog?

https://www.qbittorrent.org/news.php

[ArcticGems]

is there a full changelog?

https://www.qbittorrent.org/news.php

So sledgehammer999 excluded some of the merged PR's for later releases,
since there are merged PR's that aren't mentioned in the 4.1.8 & 4.2.0alpha2 changelog??

[thalieht]

So sledgehammer999 excluded some of the merged PR's for later releases,
since there are merged PR's that aren't mentioned in the 4.1.8 & 4.2.0alpha2 changelog??

Nah he probably just missed them. It would be helpful if you could point those PR's so they can be added in the changelog.

[FranciscoPombal]

I think this is a good time to tackle https://github.com/qbittorrent/qBittorrent/issues/10913 and https://github.com/qbittorrent/qBittorrent/issues/11112, since libtorrent 1.2.2 was just released with this feature/fix:
add torrent_info constructor overloads to control torrent file limits

I am simply trying to raise awareness for these issues in the hope that someone else can fix them, right now I really don't have the time.

[The5kull]

Can't wait for the 4.2 beta. Alpha is running smooth!

[djtj85]

Same here. 4.2.0 alpha 2 running without error.
I am waiting for the first beta

[LordNyriox]

I might as well mention that I have also been running 4.2.0 alpha 2 without any noticeable errors. My OS is Windows 10 version 1803, 64-bit, in case that is of any relevance.

[xavier2k6]

Unfortunately - Had an issue with both alpha1 & alpha2 (still unreproduced....)

Integer Divide by Zero Exception (0xC0000094)

11281

11332 -> UPDATE: managed to capture a stacktrace & attached.

Looking forward to libtorrent 1.2.2 inclusion though for mostly #3833 & having #3913 enabled or at least having the option to set it in GUI (as default is "OFF")

[sledgehammer999]

@glassez @Chocobo1 IIRC in another issue we established that the RC_1_2 fastresume format changed a little bit. I can't remember which one, but some field isn't saved anymore to file. This has the side effect that if a RC_1_2 fastresume is loaded in RC_1_1 it will trigger a torrent recheck. So basically this has meaning for users downgrading.
Should we put some sort of warning when user launches a qbittorrent instance built with RC_1_2, before continuing loading the torrents?

[xavier2k6]

@glassez @Chocobo1 IIRC in another issue we established that the RC_1_2 fastresume format changed a little bit. I can't remember which one, but some field isn't saved anymore to file. This has the side effect that if a RC_1_2 fastresume is loaded in RC_1_1 it will trigger a torrent recheck. So basically this has meaning for users downgrading.
Should we put some sort of warning when user launches a qbittorrent instance built with RC_1_2, before continuing loading the torrents?

@sledgehammer999 - are you referring to #10099?

[Chocobo1]

Should we put some sort of warning when user launches a qbittorrent instance built with RC_1_2, before continuing loading the torrents?

I think at least we should put an announcement about it on our website. About adding a warning dialog, I don't feel strongly about it... not sure.

[LordNyriox]

@xavier2k6:

are you referring to #10099?

Nope, @sledgehammer999 is referring to [https://github.com/qbittorrent/qBittorrent/pull/11104].

[glassez]

we should put an announcement about it on our website.

:+1:

Should we put some sort of warning when user launches a qbittorrent instance built with RC_1_2, before continuing loading the torrents?

I do not think that you can easily cover all users, because many of them use it without GUI, and remotely. Even in the case of GUI, you probably have to be perverted with the startup sequence... I don't think it's worth it.
One idea is to add warning in Update dialog.

[Chocobo1]

One idea is to add warning in Update dialog.

The update dialog is only available on Windows, so other users on other OS still won't get it.

[FranciscoPombal]

This has the side effect that if a RC_1_2 fastresume is loaded in RC_1_1 it will trigger a torrent recheck. So basically this has meaning for users downgrading.
Should we put some sort of warning when user launches a qbittorrent instance built with RC_1_2, before continuing loading the torrents?

IMO downgrading should not be a supported use case. Too much hassle to support. If users plan on downgrading, they should at least make a backup of their configs. If they don't do so and run into issues/inconveniences later on due to downgrading, too bad.

[djtj85]

I am waiting for the first 4.2.0 beta
4.2.0 alpha 2 still works here fine

[xavier2k6]

@LordNyriox @sledgehammer999 it was actually #10047 is where I had read it.
https://github.com/qbittorrent/qBittorrent/issues/10047#issuecomment-521656610

@sledgehammer999 Integer divide by zero issue I encountered in alpha versions has been addressed in libtorrent via 1.2 & 1.1 backport so if you can release a new alpha/beta with either 1.1/1.2 for testing would be super.

Point of Note: libtorrent upgrade to requiring C++17

[xavier2k6]

Under libtorrent section in advanced options:
"checking_mem_usage" changed -> "Outstanding memory when checking torrents"
MAX limit is "1024" as per libtorrent "DEFAULT" in documentation.
#3213 raised that to "2048", am I correct?
checking_mem_usage

Will the limit be raised in qbittorrent too?

Also:
Under libtorrent section in advanced options:
Asynchronous I/O threads is set to "4" as per libtorrent "DEFAULT" in documentation.

If I'm reading below correctly, it's now set to "8"
aio_threads

typo in changelog:
- BUGFIX: Impove DownloadManager code (glassez)
- BUGFIX: Improve DownloadManager code (glassez)
typo

[sledgehammer999]

IMO downgrading should not be a supported use case. Too much hassle to support. If users plan on downgrading, they should at least make a backup of their configs. If they don't do so and run into issues/inconveniences later on due to downgrading, too bad.

uhm no!
So you have never run into a problematic release (of any software) and went back to a known working version? Let's not be unrealistic here.

EDIT: Beta is released now.

[xavier2k6]

updated to beta now.
checks all torrents as expected at first opening.
seems more responsive while doing that.

EDIT:
high cpu usage & not responding multiple times actually.
Finished checking but upon reopening next day 70+ need to be rechecked again at startup...these had been all paused previously & hadn't been resumed so nothing should've changed??

re-opened again after a few hours & some of the twice rechecked files have to be rechecked again???

EDIT2: above has been resolved.

Noticed under taskmanager/details->threads show 270 & doesn't seem to change much.
had been able to get it at 1000+ previously...
Is something up with threading(aio threads)??

@sledgehammer999 Any reason for not updating OpenSSL to 1.1.1.d?
I presume it's because you still want to take each new addition/update at a time..........

[FranciscoPombal]

So you have never run into a problematic release (of any software) and went back to a known working version?

Yes. However, my point still stands.

[FranciscoPombal]

By the way, this is important as well: https://github.com/qbittorrent/qBittorrent/issues/11403

[Chocobo1]

@xavier2k6

"checking_mem_usage" changed -> "Outstanding memory when checking torrents"
MAX limit is "1024" as per libtorrent "DEFAULT" in documentation.

3213 raised that to "2048", am I correct?

Will the limit be raised in qbittorrent too?

Yes and no. The normal default hasn't changed, What is changed is for a set of specific settings "high performance seed" which qbt doesn't use (qbt let user set the values directly).

Asynchronous I/O threads is set to "4" as per libtorrent "DEFAULT" in documentation.
If I'm reading below correctly, it's now set to "8"

Same as above.

Let's not worry too much on those subtle discrepancy :)

[jagannatharjun]

I think #11349 should be a blocking issue since it renders new theme support kinda useless, I will try to submit the PR as soon as possible

[glassez]

I think #11349 should be a blocking issue since it renders new theme support kinda useless

I think No, since theme support is still incomplete/experimental, so we shouldn't stale on its issues so hard.

[jagannatharjun]

I think #11349 should be a blocking issue since it renders new theme support kinda useless

I think No, since theme support is still incomplete/experimental, so we shouldn't stale on its issues so hard.

But "qss" part is almost complete only big issue is #11349 (PR #11433 ), so I think at the very least first release of 4.2 should have at least "almost" working qss theme support.

[Chocobo1]

@sledgehammer999
Seems you made a redundant git tag earlier: https://github.com/qbittorrent/qBittorrent/releases/tag/help

[sledgehammer999]

IMO, the point of blocking a release is issues that affect core functionality or introduce crashes. Issues that can be fixed or improved upon on later releases shouldn't be considered as blocking.

@Chocobo1 already deleted. Apparently git tag help doesn't show the help about tag :)

[sledgehammer999]

Btw, does anyone build openssl 1.1.x on Windows by himself? If yes, does nmake test pass all tests? If yes, can you share complete instructions how you build it? From start to finish, including any manual editing of config files.

[xavier2k6]

@sledgehammer999
Old 4.2.0 Alpha with OpenSSL 1.1.1.x was built by @glassez

https://github.com/qbittorrent/qBittorrent/issues/10047#issuecomment-521656564

[ArcticGems]

Btw, does anyone build openssl 1.1.x on Windows by himself? If yes, does nmake test pass all tests? If yes, can you share complete instructions how you build it? From start to finish, including any manual editing of config files.

@sledgehammer999
Old 4.2.0 Alpha with OpenSSL 1.1.1.x was built by @glassez

#10047 (comment)

I hope OpenSSL 1.1.1.x gets included in 4.2.0. :+1:

[xavier2k6]

@ArcticGems it will as it's a requirement for Qt 5.13.x onwards.
Qt 5.13.0 requires OpenSSL 1.1.1 version on Linux and Windows.
Qt 5.14.0 requires OpenSSL 1.1.1 version on Linux and Windows.
& support for OpenSSL 1.0.x & 1.1.x ended/are ending soon.

Note

OpenSSL 1.0.2 is currently only receiving security updates. Support for 1.0.2
will end on 31st December 2019.

Support for 1.1.0 ends on 11th September 2019 so 1.1.0l is expected to be the
last 1.1.0 release.

Users of these versions should upgrade to OpenSSL 1.1.1.

[xavier2k6]

Qt 5.13.2 Released with 200 bug fixes

[xavier2k6]

I think this is a good time to tackle #10913 and #11112, since libtorrent 1.2.2 was just released with this feature/fix:
add torrent_info constructor overloads to control torrent file limits

I am simply trying to raise awareness for these issues in the hope that someone else can fix them, right now I really don't have the time.

11436 Could be reviewed/implemented - see @FranciscoPombal thoughts here

[FranciscoPombal]

Posting here for visibility: https://github.com/qbittorrent/qBittorrent/issues/11419#issuecomment-549144553

TL;DR: Adding support for forcing reannounces to occur more frequently on adding torrents/in case of tracker error can potentially kill 2 birds with 1 stone:

1. solve some of the "stalled" reports
2. make qBitorrent better for racing (this especially benefits some of the private tracker audience)

[AvailCat]

It completely break lists in WebUI for touch screen (Surface, iPad, Phone) user... #11330

[xavier2k6]

Btw, does anyone build openssl 1.1.x on Windows by himself? If yes, does nmake test pass all tests? If yes, can you share complete instructions how you build it? From start to finish, including any manual editing of config files.

@sledgehammer999 I've just tested with build found here from https://github.com/qbittorrent/qBittorrent/issues/11445#issuecomment-549781293

[Kolcha]

Btw, does anyone build openssl 1.1.x on Windows by himself? If yes, does nmake test pass all tests? If yes, can you share complete instructions how you build it? From start to finish, including any manual editing of config files.

I did. I didn't modify any files at all, just build "as is" and run tests... so, one of the tests fails. as I understood, it tests all ciphers supported by current OpenSSL build by running openssl executable and one of these checks fails. which one is unknown. I found no way to get verbose test output and I'm not familiar with Perl (tests written in Perl). I tried to add few "printf"s to test, but that completely to broke it, looks like something parses test script output and my added print statements broke this parser...
tests output is attached. fails only one check of 172 checks from the 20-test_enc.t test.
openssl-1.1.1-tests.txt

UPD: way to get verbose test output found. failed test is related to zlib... but this is pretty strange - next zlib-related test is passed:

C:\Users\Nick\Downloads\openssl-1.1.1d\apps\openssl.exe zlib -bufsize 113 -e -k test -in p -out p.zlib.cipher => 0
C:\Users\Nick\Downloads\openssl-1.1.1d\apps\openssl.exe zlib -bufsize 157 -d -k test -in p.zlib.cipher -out p.zlib.clear => 0
not ok 171 - zlib
#   Failed test 'zlib'
#   at test\recipes\20-test_enc.t line 62.
C:\Users\Nick\Downloads\openssl-1.1.1d\apps\openssl.exe zlib -bufsize 113 -a -e -k test -in p -out p.zlib.cipher => 0
C:\Users\Nick\Downloads\openssl-1.1.1d\apps\openssl.exe zlib -bufsize 157 -a -d -k test -in p.zlib.cipher -out p.zlib.clear => 0
ok 172 - zlib base64
# Looks like you failed 1 test of 172.

will continue investigation

UPD2: test fails even on Linux!! so, some kind of bug really exists. the reason of the failure is incomplete read (or write) on decryption (decompression) - it writes only first buffer (157 bytes as specified in command line) to the output file, nothing more. 100% reproducible, using any file ~200 bytes size (more than buffer size) as input.

ping @sledgehammer999

[sledgehammer999]

@Kolcha Yes. I am getting the same error. I opted to explicitly disable zlib support on openssl instead. (./config WIN64a no-zlib)
From StackOverflow it seems that it isn't a good idea to have it enabled because it can lead to being vulnerable to a class of attacks.

Can you test and verify one last thing on Windows? Do your usual ./config <options> but before issuing nmake go and edit makefile. In there find CFLAGS just change /O2 to /O1. Then when testing, do you get a fail for a test called test_test? I see this with both msvc2017 and msvc2019
This isn't a big deal since there isn't much lost from compiling with /O2 but...

[ArcticGems]

https://wiki.qt.io/Qt_5.13.2_Known_Issues

[Kolcha]

@sledgehammer999 , tested build with /O1 using msvc2019. results are the same as yours - test_test failed. I enabled verbose output (just was curious) to see what happened, and this very strange:

    # Subtest: C:\Users\Nick\Downloads\openssl-1.1.1d\test\test_test.exe
    1..20
    # ERROR: (int) '5 >= 8' failed @ test\test_test.c:48
    # [5] compared to [8]
    # ERROR: (int) '5 > 8' failed @ test\test_test.c:45
    # [5] compared to [8]
    # ERROR: (int) '9 <= 4' failed @ test\test_test.c:43
    # [9] compared to [4]
    # ERROR: (int) '9 < 4' failed @ test\test_test.c:40
    # [9] compared to [4]
    # ERROR: (int) '3 != 3' failed @ test\test_test.c:38
    # [3] compared to [3]
    # ERROR: (int) '1 == -1' failed @ test\test_test.c:36
    # [1] compared to [-1]

so changing optimization option for OpenSSL maybe a bad idea

[Chocobo1]

https://github.com/openssl/openssl/issues/8694
https://github.com/openssl/openssl/issues/9866

From StackOverflow it seems that it isn't a good idea to have it enabled because it can lead to being vulnerable to a class of attacks.

Yes, if you don't need it then disable it.

[sledgehammer999]

openssl/openssl#8694

I have reported that from April but there was no movement in that report. I now see that they tagged it ~20 hours ago as triaged. Let's hope it gets looked at. I am going to add the new info from here.

[sledgehammer999]

On another note: Here is the final game plan for 4.2.0. It seems that 4.2.0 is stable and doesn't have any serious bug pending. #11403 will be taken care of if true. So in light of this, I'll release an RC (maybe today) based on openssl 1.1.1d and libtorrent RC_1_2. Simultaneously I am going to update the source for the translation files so translators can start translating the new stuff.
We will wait on the RC and the translators until the weekend of 16th-17th November. On that weekend v4.2.0 final will be released and branched off.

[FranciscoPombal]

On another note: Here is the final game plan for 4.2.0. It seems that 4.2.0 is stable and doesn't have any serious bug pending. #11403 will be taken care of if true. So in light of this, I'll release an RC (maybe today) based on openssl 1.1.1d and libtorrent RC_1_2. Simultaneously I am going to update the source for the translation files so translators can start translating the new stuff.
We will wait on the RC and the translators until the weekend of 16th-17th November. On that weekend v4.2.0 final will be released and branched off.

Nice. However, is there any chance the stuff I mentioned above will be addressed in before the release? Or at least in the 4.2.x branch.

[sledgehammer999]

Those issues aren't blocking issues. And nothing stops us from fixing them in the 4.2.x branch in the future.

[xavier2k6]

Qt 5.14 will release at end of month......Perhaps 4.2.0 Final can be pushed out to coincide........give the RC some extra test time & translators more time to submit their changes.....might also have a complete fix for OpenSSL test issue/than workaround. (Just a thought)

New_Features_in_Qt_5.14

Qt GUI

Updated High-DPI support.
Added the QT_ENABLE_HIGHDPI_SCALING environment variable which enables high-dpi scaling based on display DPI. Replaces QT_AUTO_SCREEN_SCALE_FACTOR (now deprecated), and corresponds to the Qt::AA_EnableHighDpiScaling application attribute.
Added QGuiApplication::highDpiScaleFactorRoundingPolicy and QT_SCALE_FACTOR_ROUNDING_POLICY. Applications can now opt-in to use non-integer scale factors.
The QT_FONT_DPI environment variable is now supported cross-platform, for the purpose of developing and testing with specific DPI values.

Qt Network

HTTP/2 configuration API

Qt WebEngine

Updated to be based on Chromium 77
New API for control of QWebEnginePage life-cycle

[xavier2k6]

11448 may need some looking into.

[ryannathans]

Maybe can squeeze this one in? ;)

7743

[djtj85]

Windows 10 1903 Pro x64 with qBittorrent 4.2.0 beta works fine
I have 1000/300mbit FTTB internet and I reach every day at least 1-1,4TB upload
I run it 24/7 without any issue
;)

[sledgehammer999]

Today I updated the translations. When I run lupdate I saw the following warnings. Does someone have time to resolve them?

src/base/bittorrent/private/portforwarderimpl.cpp:103: Class 'PortForwarderImpl' lacks Q_OBJECT macro
src/base/net/downloadmanager.cpp:478: Class 'DownloadHandlerImpl' lacks Q_OBJECT macro

[Chocobo1]

Today I updated the translations. When I run lupdate I saw the following warnings. Does someone have time to resolve them?

PR #11476.

[Seeker2]

Does stub code exist for this v3.2.1 milestone item yet?:
https://github.com/qbittorrent/qBittorrent/issues/2193

[xavier2k6]

@sledgehammer999 #11485 stack overflow in 4.2.0 beta1

[xavier2k6]

@sledgehammer999 FYI
For those experiencing freezing/not responding on windows 10 - install windows 10 build 1909 (November update) & report back.....build 1909 has helped immensely on my test machines.

[Ryrynz]

Where that RC at? I expect Final is still some weeks off?

[xavier2k6]

Where that RC at? I expect Final is still some weeks off?

I believe the RC isn't happening now as the translation updates are done/being done......could be wrong - this is just my opinion!
I expect Final will happen at end of this week/start of next, unless there is a real show stopper from the already released alpha's/beta(there are some open issues with them but need more details....stack trace etc etc), as previously mentioned above - I'd prefer to have one more test version (RC) especially around the checking torrents/fastresume saves under libtorrent 1.2.x since there was changes since the beta around this area & await Qt 5.14 <- but, alas that has fallen behind it's release schedule too......

Could release 4.2.0 in December along with Qt 5.14 (should be released by then) & Boost 1.72 Releasing on Dec. 11th?? Again, that's only my thoughts but there may not be anything significant in those upcoming releases that the dev's may warrant needing to delay 4.2.0 release that can't be added in say 4.2.1 etc.

[glassez]

Although this may not be obvious (especially to people who are far from development), changing tools/libraries just before release is not a good idea (and we have already had a sad experience). This may bring some new problems.
IMO, it is better to use tested library versions for the release (i.e., those that have been used by developers for some time during the development process).

[xavier2k6]

Although this may not be obvious (especially to people who are far from development),

I hope that's a general observation & directed as such -> not a personal dig...lol

changing tools/libraries just before release is not a good idea (and we have already had a sad experience).

4.1.6/OpenSSL??

IMO, it is better to use tested library versions for the release (i.e., those that have been used by developers for some time during the development process).

That's a bit of a contradiction though isn't it since 4.1.6 was released with OpenSSL 1.1.1.x which wasn't fully compatible with Qt version at the time & we all know how that worked out.

Don't get me wrong, I'm not having a personal go at anyone or criticizing but only making suggestions & expressing my opinion -> it is just that.....an opinion.....nothing more.

For me 4.2.0 has some significant changes that I felt have had an impact on the overall experience of qbittorrent since the testing period of Alpha/Beta & even earlier releases. (In a good way)

It's only an eagerness on my part to strive to help the experience become even better.

I have always expressed appreciation to the Dev's for their work & will continue to do so.

[Ryrynz]

nothing to stop a .1 release with the new libraries after some testing. Let's not hold up the release any longer without good reason.

[p43b1]

Could be possible to add support to #3601 considering that was patched in 2016 Support DHT over IPv6 ? Thanks

[xavier2k6]

nothing to stop a .1 release with the new libraries after some testing. Let's not hold up the release any longer without good reason.

I would agree that a .N release with new libraries is sufficient & not a show stopper. (That option was only an opinion of mine) but however there are still open issues under the "Beta" Category -> these need to be investigated more & if needs be the time taken to resolve them.

My own opinion is that a "RC" should be released before final as was the previous plan but now it seems we are a "GO" for final -> what about when it's done, it's done?

As previously mentioned in a post above:

11448 may need some looking into.

That issues revolves around checking torrents & missing files........again there has been further tweaking to the checking protocol since the beta so an "RC" would help in confirming if this issue is at least resolved or would help in further debugging/tweaking.

Also those who are currently experiencing checking issues/data loss in the 4.1 branch & earlier could be requested to test an "RC" - there are a handful labeled as such.

Another issue is the stack overflow that I have encountered in the "Alpha" & "Beta" - obviously this one is going to be harder to eradicate & shouldn't be a real show stopper but it has been in/found in other versions prior to 4.2.0.

Another reason for a call on an "RC" is to confirm no issues with OpenSSL 1.1.1.x - I have tested builds with it integrated but better to be sure to be sure as the saying goes.

Again, this is just my opinion....

[sledgehammer999]

I just released RC. The final release should be next weekend at the end of the month.
I doubt that I'll use Qt 5.14 for that one. Only latest openssl and libtorrent git.

[xavier2k6]

@sledgehammer999 Thanks for RC!

[sledgehammer999]

Could be possible to add support to #3601 considering that was patched in 2016 Support DHT over IPv6 ? Thanks

It should work out of the box if you use one of the betas/RCs of 4.2.0 that uses libtorrent 1.2.x series. Remember to also use an IPv6 network adapter from the advanced settings. Although I don't know if you'll actually find IPv6 DHT nodes. I don't know if they are common or not at this point in time.

[xavier2k6]

@sledgehammer999 will #11436 make it in to 4.2.0 Final release or a 4.2.N release?

[adem4ik]

tbh for me https://github.com/qbittorrent/qBittorrent/issues/11233 is a blocking issue, I might stick to v4.1.9, cause I use links in "comment" field a lot.

[Ryrynz]

On release any chance of having an actual Qbittorrent icon for the installer rather than the nsis icon from the 1990s?

[Ryrynz]

tbh for me #11233 is a blocking issue, I might stick to v4.1.9, cause I use links in "comment" field a lot.

Fixed a few days after you posted.

[sledgehammer999]

@Chocobo1 @glassez quick vote between the 3 of us. Should I release final this weekend or another RC? I vote for final.

[glassez]

@sledgehammer999, if you use libtorrent-1.2 for official qBittorrent v4.2 builds you should apply latest fastresume related fixes. Are they already released?

[sledgehammer999]

if you use libtorrent-1.2 for official qBittorrent v4.2 builds you should apply latest fastresume related fixes. Are they already released?

On macOS/Windows where I control the releases, I'll always use latest RC_1_2. I do the same for our PPAs. The only userbase that won't have it is users using their distro's repos to install.
PS: I think the fastresume fixes about trackers is a corner case and won't affect actually users. How many users decide to suddenly erase ALL trackers and leave it empty?

[glassez]

Well, then I'm for the final release. I don't see blocking issues.
I hope you're ready to produce the next release soon after? As practice shows, we may encounter some shortcomings immediately after the start of mass use, so they should be fixed without unjustified delay.

[glassez]

@sledgehammer999, can you include #11538 in v4.2? It is very trivial.

[Chocobo1]

@Chocobo1 @glassez quick vote between the 3 of us. Should I release final this weekend or another RC?

My previous reply: https://github.com/qbittorrent/qBittorrent/pull/11520#issuecomment-558198968

@sledgehammer999, can you include #11538 in v4.2? It is very trivial.

Yes, but translators won't have enough time to translate it, minor issue though.

[glassez]

but translators won't have enough time to translate it, minor issue though.

I think it is acceptable in this particular case.

[djtj85]

I vote for RC2 because I wanna check the hungarian translates before final 4.2.0

[xavier2k6]

I vote for RC2 because I wanna check the hungarian translates before final 4.2.0

Can be fixed/updated in a 4.2.n release

11448 may be fixed in reverted/checking PR - user closed/unwilling to help in debugging further.

11123 & #11485 are still open but not currently reproducible (if ever) - debugging on-going.

"CTP to Final"

Off-topic: Not responding/freezing temporarily issues in GUI/options etc may be down to transfer list refresh rate?!, I experienced this & increased my refresh list rate & it helped...... went from 1000ms -> 5000ms (depending on amount of torrents, have to adjust accordingly)

Also unchecked "use alternating row colors"

[Chocobo1]

Not responding/freezing temporarily issues in GUI/options etc may be down to transfer list refresh rate?!, I experienced this & increased my refresh list rate & it helped...... went from 1000ms -> 5000ms (depending on amount of torrents, have to adjust accordingly)

Just curious, how many torrents do you have? v4.2.0 is supposed to perform a bit better than previous versions.

[xavier2k6]

Currently have 375.

How is the transfer list updated/rendered - qpaint via opengl or qmodelindex etc.?

[sledgehammer999]

Announcement: The toolchain builds for the 3 OSes hasn't been completed. So I expect to make the release tomorrow.

[sledgehammer999]

Announcement 2: I have finished all the builds. All that remains is some basic quality control (testing) of the builds and uploading them. But it is way too late now for me (3 am). I'll do it in a few hours after sleeping and working.
PS: @glassez @Chocobo1 The v4.2.0 has been branched off locally, but I haven't pushed that branch yet. I'll hold off until the builds are live. The master branch has been updated and you can continue merging PRs, it won't affect the release.

[j1warren]

Hi, what is the policy on change committed after a branch off?
Will it appear only in 4.3.0 or one can expect it in 4.2.1?

[LordNyriox]

@j1warren:

what is the policy on change committed after a branch off?

Historically, all commits were cherry-picked from the qBittorrent master branch to the relevant release branch, just before each release was built.

@glassez has been lobbying to permanently change this release policy to the one taken for later 4.1.x releases (where PRs from master are added to the release branch on a case-by-case basis), but AFAIK, @sledgehammer999 has insisted on continuing to use the old release method for 4.2.x.

[xavier2k6]

4.2.0 Final Released.
Download Page

[zachberger]

Congrats on the release. Any idea when it will be pushed to the PPA?

[sledgehammer999]

The release was done moments ago.
It took a while because: win32 build was crashing upon launch. It was the fault of zlib v1.2.11. After digging around on the net it turns out that for the past few years there were similar crashes reported to the one I was getting. It all stemmed from using the asm-optimized build. It turns out that the author suggests using the non-asm optimized one because, at least for Windows, the asm code resides in the contrib folder and it isn't official. It isn't maintained by him so it might be broken. So I opted to rebuild the 64bit toolchain along with the 32bit one in order to be safe from random and unexplained crashes. (and in order to follow the author's suggestions).

@j1warren the almost everything from master is cherry-picked into the stable branch. Exceptions are made for breaking changes. So yes, your PR will be appear in the next release.

@zachberger just wait a bit. On each release I have to update a lot of things to reflect the release publicly, @xavier2k6 jumped the gun. In any case, I'll point the PPA to the new branch and it should begin building the new packages. Check back in a few hours.

[Ryrynz]

Update the installer icon? It should be the qBT icon rather than some low resolution poorly antialiased icon from decades ago?

https://gyazo.com/0df814946c7870a0344deae368ee3638

[Chocobo1]

Update the installer icon? It should be the qBT icon rather than some low resolution poorly antialiased icon from decades ago?

File another issue please.