Steps for version 3.4 release

[glassez]

@sledgehammer999, @qbittorrent/frequent-contributors, as (more or less) big update coming, I would like to know how we stop. We have made many major changes to the code. What each of you expects to be there before we will release a public beta version (I hope no one was left in doubt of the need for a public beta version before the major update)?

My expectations are #5375, #5766, #6724.

[thalieht]

Considering all the icons were changed for this version, #6484 should be in as well.

[sledgehammer999]

I'll comment in a couple of hours. But now something I don't want to forget:

Isn't v3.4.0 a great opportunity to dump the ".unwanted" folder functionality? Especially now that we support 1.1.x which puts unwanted blocks into a "parts" file? My intention is to make RC_1_1 the main series for 3.4.x.

If we agree to the above, doesn't anyone volunteer to make it happen? I assume we would need a migration function too, with a notice that users can't go back to earlier versions.

[glassez]

Personally, I would also like to see [#6698], [#4029], [#3810], and [#3235], updated and merged, sooner rather than later.

I'm not sure that #4029 and #3810 can be completed in a reasonable time.

If we agree to the above, doesn't anyone volunteer to make it happen? I assume we would need a migration function too, with a notice that users can't go back to earlier versions.

Is migration required in this case? IMO, we can just stop doing it and leave existing files as is (and notice users about new behavior in release announcement).

[zeule]

Regarding libtorrent 1.1: take a look at arvidn/libtorrent#1967. Such replacement to .unwanted files might enrage users even more.

[WolfganP]

I'm just happy #5465 was merged already, so I assume it will hit v3.4.0
Due all the changes included, I support the release of a beta version (Win10 in my case) for interested users to shake up the RC a bit beforehand.

[zeule]

I actually would like to see #4994 in 3.4.0 too.

[zeule]

If we agree to the above, doesn't anyone volunteer to make it happen? I assume we would need a migration function too, with a notice that users can't go back to earlier versions.

Is migration required in this case? IMO, we can just stop doing it and leave existing files as is (and notice users about new behavior in release announcement).

From my experience it is worth to force rechecking all half-downloaded torrents after upgrading to libtorrent 1.1 in order to create and fill proper .parts files. Otherwise I/O errors pop-up when these torrent are seeded.

[zeule]

#3810 is important for Linux users only in its current state (but I wanted to add configurable notifications, i.e. user can select which event they want to see in notifications and which to ignore). As such, I don't think it has anything but minor priority, don't you agree?

[zeule]

At the same time I'd like to point you at #6156, which clearly adds benefits and needs just updating the libs for distribution/appveyour.

[Chocobo1]

To keep things manageable, maybe we can use this: https://github.com/qbittorrent/qBittorrent/projects
I've already put in my notes and devs can put in theirs too (in a new column).

[FranciscoPombal]

@glassez, @evsh, @Chocobo1, @sledgehammer999
I would also like to see #6726 addressed as well, I think it is a serious security issue.

[Seeker2]

I know there's no hope for "Alternate connections per torrent while seeding": #2193 ...making it into v3.4. I want qBT v3.4 to be released soon too.
But please consider it for a future version of qBT.

[sledgehammer999]

General comment for the rest of the devs: Guys, I'm on a tight schedule till Wednesday. Please give me time until 29th May. My top priority is to put a v3.3.13 version out containing important webui fixes. In the meantime I'll try to resume commenting on pending PRs.

[naikel]

I'm loving 3.4.0 so far. I'm really testing it now and using it daily. I found a couple of bugs in WebUI and created PRs #6818 and #6827.

[Matth7878]

Does an updated list to what is expected to be considered ready for 3.4.0 exists ?
Project "v3.4.0 release expectations" has no update since may 24th but almost all expected PR from developers have been committed. Since development has geared up it is hard not to be impatient ! :-D

[sledgehammer999]

The list should be in the release's README. But it will be a pain to make it because I have cherry-picked a lot for the v3.3.x and it will be hard to distinguish the non-cherry-picked commits from the master branch.
Probably a txt-diff comparison of the 2 commit lists will do the trick.

[bertyhell]

Are there any 3.4 build available for download anywhere? i'd like to help test the release (and see my icons in action :p)

[sledgehammer999]

Tomorrow, I'll post a beta build on the site.

[glassez]

@sledgehammer999, I'm not sure you receive alerts about inline comments in merged commits so I repost it here:

've been wanting to tell you this...
You shouldn't mention intermediate bugfixes in changelog! I.e. if some bug was introduced and then fixed between two adjacent releases it shouldn't be mentioned in changelog.

[sledgehammer999]

You shouldn't mention intermediate bugfixes in changelog! I.e. if some bug was introduced and then fixed between two adjacent releases it shouldn't be mentioned in changelog.

That's my intention. Did I miss something?

[pasha-zzz]

Maybe #6569 and #6059 too?

[sledgehammer999]

Refactor and improve statusBar is also a fixup commit, FYI.

I think it contains extra stuff.

[sledgehammer999]

@qbittorrent/demigods I am planning to do stable release of master the next weekend. Also I am thinking of bumping the version to 4.0.0 instead of 3.4.0. Is that ok?
(of course the v3_4_x branch will be renamed too)

[glassez]

Also I am thinking of bumping the version to 4.0.0 instead of 3.4.0. Is that ok?

If you have reason to do it... Of course, it would be better to do it starting with beta release (it looks strange v4.0 after v3.4beta).

I am planning to do stable release of master the next weekend.

New RSS subsystem has one reported bug. I can't fix it without affected feed urls but Issue author still don't provide me necessary info.

[Chocobo1]

I am planning to do stable release of master the next weekend.

I'll try to make #3235 ready in time.

Of course, it would be better to do it starting with beta release

+1

[sledgehammer999]

If you have reason to do it...

ΙΜΟ, the jump from 3.3.x to 3.4.x seems small for the amount of differences between. Also early v3.3.x releases(eg 3.3.3) are quite different in features/capabilities from current code. So I just wanted to signal the evolution via version number too.

I'll try to make #3235 ready in time.

Sure, but it can safely go into v4.0.1 too.

New RSS subsystem has one reported bug. I can't fix it without affected feed urls but Issue author still don't provide me necessary info.

Do you think it important enough to wait more?
In case of a stable release there might be new reporters with better info.

[naikel]

What's the one reported bug for the RSS subsystem? I can only found two issues: one already fixed that only magnet links work and direct http links don't, and another one where the user has a Mac and can't try 3.4.0 beta.

[glassez]

What's the one reported bug for the RSS subsystem?

Well, there's no separate Issue for thos problem. See last comments of #3898.

Do you think it important enough to wait more?

No, I don't.

[sledgehammer999]

An update: The final release is pushed back till next weekend unfortunately. I was planning to review/merge the PR for the logo this past week. But unforeseen events rendered me inactive in the project. I should be able to merge that PR during this week. Otherwise, I'll post a 2nd beta next weekend instead of a final version.

Of course, pending small PRs and hotfixes will be merged too.

I wonder what's the target for 3.4.0 as there was a lot of discussion and development effort on v1.1 lately, with adoption of new lib features and the infamous mem leak... could anyone confirm?

That's why all those issues were discovered, reported and fixed. Because RC_1_1 is in the qbt spotlight now.

I need to recompile everything then, cause when building qb from scratch with libtorrent RC_1_1 in my raspberry 2, qbittorrent-nox now stops with:

You must make sure that it compiles/links against >= 1.1.2. Earlier versions don't contain libtorrent::generate_fingerprint().
(and yes, it is deliberate that we don't use a patch for earlier versions)

[sledgehammer999]

You must make sure that it compiles/links against >= 1.1.2.

Of course, it still can compile/link against RC_1_0 too. But RC_1_1 is the main focus now.

[sledgehammer999]

QFileIconProvider isn't essential IMO.

EDIT: The affected libs from 1.65 aren't used by us and libtorrent. So no issue there either.

[sledgehammer999]

It will depend if I have enough time to recompile said libs and their dependants.

[RabidWolf]

Also, I have been wondering if you might offer builds based on Libtorrent 1.0.x in addition to ones based on Libtorrent 1.1.x, for Windows users?

What's the difference between the 2?

[sledgehammer999]

What's the difference between the 2?

libtorrent 1.1.0 changelog. Partly fixes and partly features. Fixes might be backported to the RC_1_0 branch but not the features.

Also, I have been wondering if you might offer builds based on Libtorrent 1.0.x in addition to ones based on Libtorrent 1.1.x, for Windows users?

No.

[WolfganP]

I know this maybe too naive, but couldn't find it in the makefiles' set. Which flag do I need to pass ./configure to choose debug / release build version?

And I assume that even opting for a debug build, the -nox compilation will be a quiet one while running and just log to /var/log/qbittorrent-nox.log?
Thanks!

[Chocobo1]

I know this maybe too naive, but couldn't find it in the makefiles' set. Which flag do I need to pass ./configure to choose debug / release build version?

have you tried?
./configure --help

it says:

--enable-debug          Enable debug build

[WolfganP]

@sledgehammer999

You must make sure that it compiles/links against >= 1.1.2. Earlier versions don't contain libtorrent::generate_fingerprint().
(and yes, it is deliberate that we don't use a patch for earlier versions)

I did recompile libtorrent RC_1_1 (v1.1.4 at this time) and qB master head as previously suggested from scratch, and still suffering the dreaded fingerprint error. As per gdb:

Starting program: /usr/bin/qbittorrent-nox --webui-port=8099
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0x74046a70 (LWP 10038)]
[New Thread 0x7343aa70 (LWP 10039)]
/usr/bin/qbittorrent-nox: symbol lookup error: /usr/bin/qbittorrent-nox: undefined symbol: _ZN10libtorrent20generate_fingerprintENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiiii
[Thread 0x7343aa70 (LWP 10039) exited]
[Thread 0x76fef000 (LWP 10032) exited]
[Inferior 1 (process 10032) exited with code 0177]

I didn't observe any linking or compilation error during the process, and checked any fingerprint piece of code is actually compiled when building libtorrent. Any idea what it may be?
Thanks.

[zeule]

If it compiles but does not run, this might indicate that your binary is stripped and LD_PATH contains another copy of libtorrent-rasterbar.so

[WolfganP]

If it compiles but does not run, this might indicate that your binary is stripped and LD_PATH contains another copy of libtorrent-rasterbar.so

Success! The /var/lib path had a copy of libtorrent-rasterbar8 that surely was generated a while ago and that interfered with qB building process. Now v3.4.0alpha working with libtorrent v1.1 !!!

Thanks a lot for all your help!

My only remaining wish is just that #5465 "Root folder strip" is exposed to the webUI add torrent window and that will complete my happy transition to qB! Thanks again!

[sledgehammer999]

Yet another tiny update: I realize that it is a bit long since last stable release. So now I am cherry-picking critical commits(eg the one that chooses wrong listen interface) and will do a v3.3.16 release along with a v3.4.0beta2 release. Stay tuned. I should be done in 3-4 hours.

[glassez]

bda5be8 is very important for v3.3.16 .

[glassez]

...will do a v3.3.16 release along with a v3.4.0beta2 release. Stay tuned. I should be done in 3-4 hours.

BTW, this is good point to rename v3.4 to v4.0 if you still want to do it (and release v4.0.0beta or beta2).

[sledgehammer999]

bda5be8 is very important for v3.3.16 .

I agree.
Also what should I do with 5f47d3b and f067b8b? They seem related to stripFolder which isn't backported. Do they fix something that should be fixed in v3.3.16 too?

BTW, this is good point to rename v3.4 to v4.0 if you still want to do it (and release v4.0.0beta or beta2).

Normally, yes. But I have discovered a possible side-effect of the current "beta" situation. Trackers that rely only at the peer-id will not be able to differentiate between v4.0.0beta and v4.0.0 stable. So since the "v3.4.0" is burned already, I intend to continue the betas like that, and instead mention the future transition to v4.0.0 in the news entry.

[glassez]

Do they fix something that should be fixed in v3.3.16 too?

Don't think. Leave it for 3.4.

[WolfganP]

Any way that a quick prototype of #7217 WebUI off-program extensions can be implemented so actual alt WebUI mods like @naikel (#6882 (comment)) can be start to be worked on with core and maybe be included in official 3.4.0 if the feature matures enough? (I always think that visual features like UI / WebUI changes always get big attention from users due it's "materiality" :-)
Thanks!

[Amaunator]

hi all! On Arch with boost 1.65 neither version works: from repos nor compiled from the source. libboost_system.so.1.64.0: cannot open shared object file: No such file or directory

compile errors:
compiling base/net/portforwarder.cpp compiling base/net/proxyconfigurationmanager.cpp compiling base/net/reverseresolution.cpp In file included from /usr/include/libtorrent/version.hpp:36:0, from app/upgrade.h:32, from app/main.cpp:79: /usr/include/libtorrent/export.hpp:37:12: fatal error: boost/config/select_compiler_config.hpp: No such file or directory include <boost/config/select_compiler_config.hpp> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[1]: *** [Makefile:2935: main.o] Error 1

[Chocobo1]

hi all! On Arch with boost 1.65 neither version works: from repos nor compiled from the source. libboost_system.so.1.64.0: cannot open shared object file: No such file or directory

you need to rebuild libtorrent-rasterbar with boost 1.65.

[sledgehammer999]

Some news: The logo PR (#6484) is almost ready for merging. I am also going to update the .ts files for the translators to work again on them. Because of that, to give them time, I think I shouldn't release sooner than the coming Wednesday.
Is #7445 still being considered for v4.0.0? Is there any other issue that should stall the final release?

[Chocobo1]

Is #7445 still being considered for v4.0.0?

Yes, it's been stalled because we couldn't make an agreement, yet I think its worth a try.

[Seeker2]

There's some serious functionality problems that need to be addressed eventually, but they may have to wait till after this is released.

UPnP, tracker issues, ip bans, high cpu and memory usage, possible crashes.

[sledgehammer999]

If I find time tomorrow I am going to release v4.0.0. Should I wait for some specific PR first?
PS: #6484 will be merged just before releasing.

[ghost]

@sledgehammer999 What about #6484?

[Chocobo1]

Should I wait for some specific PR first?

#7636, the feature (noted in change log) isn't really complete without the fix.
Can you make a little time fixing it?

[sledgehammer999]

PS: #6661 will be merged just before releasing.

@DrunkenSasquatch I messed up the numbers. I meant #6484.

[sledgehammer999]

v4.0.0 is released. Thanks for your contributions.

Please take a look at the incoming bug reports.
Sometimes I am going to assign you to an issue. If you don't feel like fixing, just un-assigned yourselves.
And feel free to self-assign to issues too.