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

[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 #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.

[The5kull]

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

[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 [#11104].

[glassez]

we should put an announcement about it on our website.

👍

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.

[xavier2k6]

@LordNyriox @sledgehammer999 it was actually #10047 is where I had read it.
#10047 (comment)

@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: #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

[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 #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: #11520 (comment)

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

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