@sledgehammer999你应该阅读这个 => https://github.com/orgs/qbittorrent/teams/bug-handlers/discussions/5

谢天谢地没有病毒（我希望我保持这种状态）。

我个人为你感到高兴。

但我对项目目前的状况感到非常难过（而且我不是唯一一个有同样感受的人）。 变革的时机至关重要。 因此，您必须要么重组项目的管理/维护，要么明确声明它只是您的个人玩具，以免其他人抱有虚假的希望。

是否有任何必须豁免的提交？

我认为现在跳过任何更改是没有意义的。

无论如何，新版本早就应该发布了。

太多了。

我应该像往常一样将所有新的主提交向后移植到 v4_2_x 分支吗？

为什么选择 v4.2.x？ v4.3 有更多的变化！
此外，您可以简单地在当前 master 之上创建 v4_3_x 分支，而不是通过“挑选”提交来做这些不必要的工作。

我刚刚看完了从上一版本到最新版的提交。 （主要提交标题和 PR 描述）

为什么选择 v4.2.x？ v4.3 有更多的变化！

是的。 有大量的提交。 而且由于 libtorrent 1.1.x 已被删除，它肯定需要 v4.3.x。 （以及用于 libtorrent 2.0.x 和 c++17 的 v4.4.x ！！！）
我会尽快为即将到来的变更日志创建一个新的 PR。

关于项目管理：我们将在周末/即将发布的版本之后讨论这个问题。

@sledgehammer999

很高兴你回来了，一切都好。

我应该像往常一样将所有新的主提交向后移植到 v4_2_x 分支吗？ 是否有任何必须豁免的提交？

我对给新版本 4.3.x 贴标签的提议无动于衷。 由您和其他人决定。

所有提交都是好的 AFAIK。 但是，许多非常重要的修复程序也已合并到 libtorrent，因此在此新版本中使用可能的最新RC_1_2非常重要。

已经有几个关于 BitTorrent V2 支持的提交。 但是，我希望这个版本是用上面提到的最新的 libtorrent RC_1_2构建的，所以大多数用户在实践中都看不到它。 因此，我会在更改日志中添加注释来解释这一点，以便用户在阅读与 BitTorrent V2 相关的条目时不会抱有错误的希望。

我已经更新了我的本地工具链。 backporting/changelog/minimal 测试需要一些时间。 但我认为这个周末是一个可行的目标，具体取决于变化的大小。

你能提供这方面的细节吗？ 我假设您拥有最新的 MSVC 2019，并且我_希望_您正在使用 vcpkg 或类似的依赖项 - 由于所有构建方式的细微差异和更高的可重复性，出现奇怪错误的可能性较小。 您可以查看新的 GitHub Actions CI 以获取灵感。 另外请记住这次使用 CMake 进行构建，它已成为新的默认构建系统。

关于项目管理：我们将在周末/即将发布的版本之后讨论这个问题。

好的，但请早点而不是晚点。 而且我们必须继续讨论进一步自动化发布过程，以便甚至可以自动完成打包。

@sledgehammer999

另外，请在此过程中清理 PPA。 除18.04 、 20.04和20.10之外的 Ubuntu 版本已停产，因此应尽快删除针对这些版本的构建存档。

所以在这个新版本中使用最新的可能的 RC_1_2 很重要。

这是不言而喻的。
Qt 15.1，openssl 1.1.1h，提升 1.74

RC_2_0 还不会被使用。 并非没有几个官方测试版。

我假设您拥有最新的 MSVC 2019，希望您使用的是 vcpkg

不，对于这个版本，我仍然使用 msvc2017。 上次我检查 msvc2019 时，它为 qbt 生成了非常大的 .pdb 文件。 我稍后会再次检查，但不是针对此版本。
其余的依赖项都是按照我一直做的方式构建的。 或多或少在这里描述： https ://github.com/qbittorrent/qBittorrent/wiki/Compiling-with-MSVC-2019-（静态链接）

另外请记住这次使用 CMake 进行构建，它已成为新的默认构建系统。

显然我在 git 日志中错过了这个。 我有点沮丧，但我不能真正反对它，因为所有其他人都觉得使用 cmake 比使用 autotools/qmake 更舒服。
但是，暂时我将继续使用 autotools/qmake 进行发布。 我没有时间熟悉 cmake 的发布。

我会看看如何处理 PPA，尽管它们不会伤害任何人。

@ sledgehammer999我知道您不希望普通用户在这里发表评论，所以很抱歉......我一直在这里构建 Windows 以解决问题/错误等。

我用 MSVC 2019 编译 & qBittorrent 可执行文件通常约为 27 MB & .pdb 为 180 MB

你有没有想过使用/pdbstripped ？

我用 MSVC 2019 编译 & qBittorrent 可执行文件通常约为 27 MB & .pdb 为 180 MB

与 msvc2017 和当前 master 相比：24.4MB exe 和 98.1MB pdb。 正如我所说，与 msvc2017 相比，pdb 非常大。

我也不认为我们想要 /pdbstripped。 当程序崩溃时，它可能会提供不太有用的回溯。

我也不认为我们想要 /pdbstripped。 当程序崩溃时，它可能会提供不太有用的回溯。

/PDBCompress ?

@sledgehammer999

使用 CMake + 最新的 MSVC 2019 + vcpkg (https://github.com/qbittorrent/qBittorrent/actions) 的自动化 CI 构建为 57 MiB (executable) + 122 MiB (pdb)。

不，对于这个版本，我仍然使用 msvc2017。 上次我检查 msvc2019 时，它为 qbt 生成了非常大的 .pdb 文件。 我稍后会再次检查，但不是针对此版本。

这不是 IMO 的好理由。 MSVC 2019 包含许多修复。 现在是 2020 年（年底）。没有人关心额外的 \~50 MiB 安装大小（如果他们这样做，那就太糟糕了，哈哈）。 如果有什么东西使 pdb/可执行文件膨胀，我们可以稍后弄清楚，但现在一切正常，额外的 \~50 MiB 是我在一周中的任何一天为更新的工具链做出的权衡。

我也不认为我们想要 /pdbstripped。 当程序崩溃时，它可能会提供不太有用的回溯。

:+1:，但这可以在未来进行适当的调查。

其余的依赖项都是按照我一直做的方式构建的。 或多或少在这里描述： https ://github.com/qbittorrent/qBittorrent/wiki/Compiling-with-MSVC-2019-（静态链接）

显然我在 git 日志中错过了这个。 我有点沮丧，但我不能真正反对它，因为所有其他人都觉得使用 cmake 比使用 autotools/qmake 更舒服。
但是，暂时我将继续使用 autotools/qmake 进行发布。 我没有时间熟悉 cmake 的发布。

:-1:，这不是过去几个月大多数人在 Windows 上测试 qBittorrent 的方式。 很多人都在使用我的 CI 分支（CMake + vcpkg）的构建，现在是 repo 自己的 Actions 部分。 我想说，如果你这样做，我们很可能会观察到由于构建过程的差异而产生的无法解释的回归。

@sledgehammer999我不想在发布之前再添加“拦截器”，但至少我会等待它落地，因为它基本上已经准备好了： https ://github.com/qbittorrent/qBittorrent/pull/13499

更改异步 I/O 线程的默认值将对许多用户有利。

我不想diss msvc2019，但我认为你在考虑一切全新的更好方面有点过头了。 并非总是如此。 是的，对于一个 bt 客户端来说，额外的 50MB 是一件大事。 没有任何可衡量的好处是不必要的膨胀（例如，程序没有变得快 1.5 倍）。

最后关于构建系统：如果我们仅仅看到构建系统变化的回归，那么代码就会出现严重错误。 东西不应该那么脆弱。

13499 超出范围，因为它与 libtorrent 2.0.x 选项有关，但还不是默认选项。 最后将在周末进行削减。

@sledgehammer999

我不想diss msvc2019，但我认为你在考虑一切全新的更好方面有点过头了。 并非总是如此。
是的，对于一个 bt 客户端来说，额外的 50MB 是一件大事。 没有任何可衡量的好处是不必要的膨胀（例如，程序没有变得快 1.5 倍）。

请不要仅仅将我的论点视为“新=更好”。 而且我认为您坚持使用更糟糕的工具链来获取 50 MiB 有点“过头”。 当然，您永远不会（或很少）看到更新工具链的速度提高了“1.5 倍”。 但这是一个不切实际的标准。 使用更新的工具链可能不会有“1.5 倍”的加速，但总会有小的性能改进、更好的语言支持、更好的代码生成（有时会导致更少的错误）……有大量的在线资源记录MSVC 2019 的改进。

同样，我同意我们应该尽可能减少额外的 50 MiB，但我的观点是，如果我们不能及时为下一个版本（或永远！）做到这一点，_没关系_。 此外，这并不意味着每次发布都会再次发生这种情况（在这种情况下我也会很生气）。 这显然是一个一次性的问题。 作为用户，我不想听到“这是您的质量较差的二进制文件，但至少我们为您节省了 50 MiB，兄弟”。 50 MiB 现在是一个舍入错误（无论如何，对于桌面程序；当然在嵌入式世界中，情况并非如此）。 对不起，如果你不这么想，那你就错了。

最后关于构建系统：如果我们仅仅看到构建系统变化的回归，那么代码就会出现严重错误。 东西不应该那么脆弱。

不必要。 构建系统本身可能存在严重问题。 在我的大修 PR 之前，请查看 CMake 构建系统的先前状态。 在此之前，使用 CMake 构建会导致很多错误。 一些（有时很严重！）问题确实源于不正确/糟糕的构建系统和构建配方。 无论您的代码多么健壮，如果您构建错误，它就会崩溃，有时会以非常壮观但难以诊断的方式破坏。

13499 超出范围，因为它与 libtorrent 2.0.x 选项有关，但还不是默认选项。 最后将在周末进行削减。

请参阅讨论的其余部分。 该 PR 实际上还更改了异步 I/O 线程的默认数量，因此默认情况下，在针对 libtorrent 1.2.x 构建时也至少使用 2 个哈希线程。 这为 SSD 用户带来了非常显着的性能提升（实际上超过 1.5 倍，呵呵），同时也为 HDD 用户提供了非常小的收益。

@sledgehammer999

以下是一些帮助您入门的方法：

• 在 Windows 上使用 CMake 静态构建的新教程： https ://github.com/qbittorrent/qBittorrent/wiki/Compilation :-Windows-(MSVC-2019,-64-bit,-static-linkage)
• 选项列表 + 简短的 CMake 教程/介绍： https ://github.com/qbittorrent/qBittorrent/wiki/Compilation-with-CMake :-common-information

如果您没有使用 vcpkg，或者如果您对某些软件包使用 vcpkg 而不是其他软件包，您只需要另外传递适当的提示，告诉 CMake 在哪里可以找到 pacakges 的配置文件，例如-DLibtorrentRasterbar_DIR=C:\path\to\libtorrent-install-dir\lib\cmake\LibtorrentRasterbar . 如果有疑问，您可以简单地运行配置，直到它成功，在它们弹出时一次修复有关每个包的每个错误消息，因为错误消息非常有用，您可以随时理解并找出需要添加的内容下一个。

我不会进一步争论编译器。 我不同意你专门针对qbt。 一旦我们切换到 c++17，msvc2019 对我们来说将变得更加相关。 最后，对于一个bt客户端用户来说，他关心的只是客户端是否可以实现自上而下/向上的速度。 这是“更好”或“更差”质量二进制的指标。 msvc2017 在没有额外膨胀的情况下实现了这一点。 --在我用 msvc2019 重做我的构建之前，我持有我的判断 --

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

构建/安装软件包的方式是否有所不同？ 目前我在lib下没有任何 boost、libtorrent、openssl 的cmake文件夹。 仅适用于 qt。
PS：boost 和 libtorrent 是使用 b2 构建的。 Openssl 使用他们的配置脚本。

@sledgehammer999

唯一的要求是您使用 CMake、IIRC 构建 libtorrent。 所有其他包要么默认生成所需的配置文件，要么以某种方式受 CMake 支持：

• libtorrent 必须使用 CMake 构建才能生成适当的文件。 这在 Wiki 教程中有专门介绍。
• CMake 通过捆绑的查找模块原生支持 OpenSSL： https://cmake.org/cmake/help/latest/module/FindOpenSSL.html#hints。 你只需要设置OPENSSL_ROOT_DIR 。 示例： -DOPENSSL_ROOT_DIR=C:\Qt\Tools\OpenSSL\Win_x64
• boost 默认生成所需的文件。 您只需设置Boost_DIR示例： -DBoost_DIR=C:\path\to\boost_1_73_0\stage\lib\cmake\Boost-1.73.0
• 对于 zlib，您必须通过一些路径。 示例： -DZLIB_INCLUDE_DIR=C:\path\to\zlib-1.2.11\build -DZLIB_LIBRARY=C:\path\to\zlib-1.2.11\build\libzlibstatic.a
• Qt 会生成所需的文件，我假设您已经确定了指向它们所需的配置时间标志。

同样，如果您缺少其中任何一个，CMake 将在配置步骤中告诉您相关信息，并准确建议您添加的内容。

我同意大锤999。
较小的二进制文件总是更好。 特别给出了过去版本的跟踪记录。
许多人的互联网速度仍然很慢。基于位置的某些用户，提供二进制文件的网站也可能很慢。
在这种情况下，一个小的二进制文件可以加快下载速度。 如果人们怀疑不必要的过时软件，他们可能会气馁更新。

它已成为新的默认构建系统。

默认构建系统是什么？

它已成为新的默认构建系统。

默认构建系统是什么？

他甚至宣布不推荐使用 qmake/autotools https://github.com/qbittorrent/qBittorrent/wiki

他甚至宣布不推荐使用 qmake/autotools https://github.com/qbittorrent/qBittorrent/wiki

这种随意性开始真正激怒了！

它已成为新的默认构建系统。
默认构建系统是什么？

这种随意性开始真正激怒了！

哦哇！ 所以这不是一个实际的决定！ 毕竟我并不感到沮丧。

@FranciscoPombal
请不要用关于不同构建工具、构建系统等的无用对话来分散@sledgehammer999的注意力。让即将发布的版本以通常的方式完成——它会更快、更可靠。 我们需要时间来解决组织问题，这样我们才能让项目继续运转，不管它的一个成员消失了很长时间。
在即将发布的版本（以及整个即将发布的分支）的上下文中讨论 libtorrent-2.0 也是没有意义的，因为我们不支持它，我们甚至无法预测它何时会完全实施。

现在是 2020 年（年底）。没有人关心额外的 ~50 MiB 安装大小（如果他们这样做，那就太糟糕了，哈哈）。

我的两台主要计算机分别是 9 年和 12 年（尽管我最近通过将 SSD 安装为系统磁盘对它们进行了改进）。 许多人甚至使用较旧的硬件。 这不是因为我们喜欢它。 我们只是没有财务/其他能力每 2-3 年更新一次。 如果您无法理解我们，它仍然没有给您取笑我们的权利。

PS 然而，即使在 10 年前，我也不会对这 50 兆字节如此担心。

@an0n666 @ sledgehammer999 @glassez

我同意大锤999。
较小的二进制文件总是更好。 特别给出了过去版本的跟踪记录。
许多人的互联网速度仍然很慢。基于位置的某些用户，提供二进制文件的网站也可能很慢。
在这种情况下，一个小的二进制文件可以加快下载速度。 如果人们怀疑不必要的过时软件，他们可能会气馁更新。

来吧，应用程序下载是一次性费用。 即使是 10 Mb/s，额外的 50 MiB 也只是额外的 50 秒。 如果这些人对此感到困扰，他们最好他妈的来这里并帮助自己解决问题。 不要让自己被抱怨 50 MiB 的强迫症患者左右。 他们想因此切换回 uT 2.2.1？ 美好的。 即使在索马里，您平均可以获得 10 Mb/s： https ://www.speedtest.net/global-index，我怀疑 BitTorrent 客户端是大多数索马里本地人的主要关注点。 这些构建由 Fosshub 和 Sourceforge 提供，除非 Kim Kardashian 告诉她的所有粉丝下载 qBittorrent 或其他东西，否则它们不太可能成为瓶颈。

还，

较小的二进制文件总是更好。 特别给出了过去版本的跟踪记录。

需要引用。 “更好的记录”和“更小的二进制大小”之间的相关性在哪里？ 更好的跟踪记录是什么？ 表现？ 可靠性？

默认构建系统是什么？

他甚至宣布不推荐使用 qmake/autotools https://github.com/qbittorrent/qBittorrent/wiki

这种随意性开始真正激怒了！

哦哇！ 所以这不是一个实际的决定！ 毕竟我并不感到沮丧。

我们确实同意 CMake 构建系统是未来。 正如我之前多次说过的，保持两个构建系统是错误的。 最近的贡献中甚至提到了这一点： https ://github.com/qbittorrent/qBittorrent/pull/13509#issuecomment -708072078

说到英国媒体报道：看看我们因维护 2 个构建系统而付出的重复努力。 查看我们在 repo 中的几个 autotools bloat 文件。

请不要用关于不同构建工具、构建系统等的无用对话来分散@sledgehammer999的注意力。让即将发布的版本以通常的方式完成——它会更快、更可靠。

又一次攻击可能是该存储库中过去几个月中最活跃的成员，谁做出了重要贡献，特别是在构建系统、工具等领域。新构建和对构建系统的修改_are_更可靠。 我记得，甚至有一些问题只是通过使用新方法构建就消失了。 多亏了我的努力，我们现在可以更快地将更可靠的构建交付给用户。 这当然不是没用的。 我计划进一步改进这一点，直到正式发布，但如果你继续这样贬低我的参与，请不要指望我。

我不会分散他的注意力，而是让他了解过去几个月的重要发展。 他有责任赶上。
现在雪橇回来了，我想和任何人一样把建筑搬出去，但我想做_对_。 sledge 回归不应该意味着我们必须回到我们的旧方式（即使这个版本感觉像是一种妥协），它应该意味着我们可以进化_更快_到达我们想要的地方。

我们需要时间来解决组织问题，这样我们才能让项目继续运转，不管它的一个成员消失了很长时间。

部分问题是依靠一个人手动生成具有老化且可维护性较差的构建系统的构建，仅仅因为 50 MiB（可以稍后解决）而跳过箍，等等。考虑我们正在偏离的事实我们在 CI 中使用的工具链就是为了这个。 即使它现在实际上不是一个大问题，它也是一个糟糕的原则和先例。

在即将发布的版本（以及整个即将发布的分支）的上下文中讨论 libtorrent-2.0 也是没有意义的，因为我们不支持它，我们甚至无法预测它何时会完全实施。

我们根本不需要谈论 libtorrent 2.0。 只是一个小注释解释了对 V2 的支持仍然不存在，尽管事实上在更改日志的提交消息中会出现一些对 V2 支持的提及。 例如，19d77b0881dc777b7930106869854067e5b2faba。 （当然，除非您不为 4.3.0 版本挑选那些提交，但这会使 IMO 变得复杂）。

我的两台主要计算机分别是 9 年和 12 年（尽管我最近通过将 SSD 安装为系统磁盘对它们进行了改进）。 许多人甚至使用较旧的硬件。 这不是因为我们喜欢它。 我们只是没有财务/其他能力每 2-3 年更新一次。 如果您无法理解我们，它仍然没有给您取笑我们的权利。

PS 然而，即使在 10 年前，我也不会对这 50 兆字节如此担心。

请指出我“取笑”低规格用户的地方。 我也有一台 12 年的 C2D 笔记本电脑，我在上面安装了 SSD（虽然连接只有 SATA II！），但我仍然经常使用。 我也没有任何配备过去 3 年制造的处理器的机器，我希望将来能获得 AMD Ryzen。 我当然不会“每 2-3 年升级一次”。 我理解并同意你的看法。 我只是取笑现在抱怨台式机/笔记本电脑上 50 MiB 的人（阅读：过去 15 年以上），因为这些人值得被取笑。

在过去的几个月里，对可能是该存储库中最活跃的成员的又一次攻击

请停止在我的评论中寻找一些隐藏的潜台词。 我只是说了我说的话。 我希望你的反应不会让任何人感到困惑。

我不会分散他的注意力，而是让他了解过去几个月的重要发展。 他有责任赶上。

一切都有它的时间和地点。
为什么要在这里和现在按@sledgehammer999 ，如果这只会导致他没有时间做下一个版本，也没有时间在他再次消失之前重组项目的管理/维护，这样我们就不会能够在他不在的情况下继续全面的工作。

我们根本不需要谈论 libtorrent 2.0。 只是一个小注释解释了对 V2 的支持仍然不存在，尽管事实上在更改日志的提交消息中会出现一些对 V2 支持的提及。

我反复提到过，更改日志不应该盲目复制 git 历史。 你应该记住：

1. 一些提交是单个修复/改进/功能的一部分，因此完整提及它是有意义的；
2. 一些提交修复了以前版本中不存在的中间错误，因此提及它们是没有意义的；
3. 一些提交是一些未完成工作的一部分，因此提及它们是没有意义的。

@sledgehammer999
请通知问题 #13519。

编辑：误报： https ://github.com/qbittorrent/qBittorrent/issues/13519#issuecomment -710744534
编辑（FranciscoPombal）不是虚惊一场： https ://github.com/qbittorrent/qBittorrent/issues/13519#issuecomment -710911209

@ sledgehammer999 @Chocobo1 @glassez

很抱歉大量 ping，但这似乎也相当重要，不幸的是现在有点混乱（此时我也很困惑到底是什么问题）： https ://github.com/

一件事是肯定的； 我不想冒险在第一个 4.3.x 版本中破坏每个人的*arr设置。

这似乎也相当重要，不幸的是现在有点混乱（此时我也很困惑到底是什么问题）：#13389。 也许你们中的一个人可以对此有所了解？

一件事是肯定的； 我不想冒险在第一个 4.3.x 版本中破坏每个人的*arr设置。

请不要在最后开始吓坏了。 有什么问题？ （除了理解应用程序逻辑的问题。）我们没有更改相关代码，是吗？ 我当然没有阅读整个线程。 如果有明确的证据表明应用程序存在错误，请指出我的具体评论。

@glassez

请不要在最后开始吓坏了。 有什么问题？ （除了理解应用程序逻辑的问题。）我们没有更改相关代码，是吗？ 我当然没有阅读整个线程。 如果有明确的证据表明应用程序存在错误，请指出我的具体评论。

没有人吓坏了，我们只需要意识到潜在的后果。 重点是让其他人以清晰的头脑仔细阅读线程。 当我试图解决它时，我无法确定这是合法的回归还是用户对最近更改的错误陈述，或者最近的措辞更改是否暴露了意外的缺陷或什么。 更糟糕的是，我实际上从未使用过任何*arr软件，但我知道很多人都使用过。 无论如何，这里是*arr存储库中的原始报告： https ://github.com/Radarr/Radarr/issues/5032 https://github.com/Sonarr/Sonarr/issues/3968 ，如果你想看看。

大家好，

我刚刚注意到有人在之前的评论中提到了 FOSSHUB。 我已经阅读了该主题并想说这一点。 假设 qBittorrent 大约有 50 MB，这对我们没有任何影响。 任何流量高峰都一样，有人提到金卡戴珊。 请她推荐qBittorrent； 我相信我们不会倒下。 我们可以吸收这些流量。 例如，每当发布新的 qBittorrent 时，我们都会看到每秒数千个更新请求。

我想说的是，你不应该担心这个。

谢谢！

无论出于何种原因，我的 1.5cents 它确实在 msvc2019 上构建和运行得更好
50mb 的磁盘空间在 2020 年绝对不算什么，如果您的系统受到限制，那么您无论如何都在运行更轻量级的客户端或 qbt-cli

永远不要推迟让你的项目升级到最新和最好的版本，因为它可以在不引起错误的情况下完成你等待的时间越长你落后的风险就越大

我认为 sledge 指的是即使在安装程序大小仅增加 12 MiB 之后也会打开这些问题。
https://github.com/qbittorrent/qBittorrent/issues/12247

因此，人们创建问题单的长度甚至不是 50 MiB，而是 12 MiB。

@sledgehammer999 “如果”你将在下一版本中使用Qt 5.15.0/5.15.1 ，请注意（选择一个标签后上下文菜单关闭）#13492

简单地说，我认为如果它被标记为 4.3，没有人会抱怨安装程序更大，这肯定是可以预料的！ 老实说，与过时的工具链保持一致感觉就像是 qBittorrent 发布过程的恰当表示。

很高兴终于看到这种情况发生，我几乎放弃了今年看到一些东西的希望。

我认为 sledge 指的是即使在安装程序大小仅增加 12 MiB 之后也会打开这些问题。

12247

>

因此，人们创建问题单的长度甚至不是 50 MiB，而是 12 MiB。

所以？ 对此类票证的唯一适当回应是“无论如何，伙计。”。 我不理解这些人对向后弯腰的痴迷。 就像我在https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -708436739 中所说的那样，我们当然会尽最大努力防止尺寸增加，但我们不应该仅仅为了 50 MiB，如果有些人对此感到困扰，他们可以来这里自己解决。

我们不应该牺牲其他任何东西

很抱歉，但我真的看不出我们不使用最新最好的（怀疑）编译器会牺牲什么。 使用最新的编译器没有任何实际意义。 msvc2017 并不是一个古老的编译器。

@sledgehammer999

很抱歉，但我真的看不出我们不使用最新最好的（怀疑）编译器会牺牲什么。 使用最新的编译器没有任何实际意义。 msvc2017 并不是一个古老的编译器。

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

无论出于何种原因，我的 1.5cents 它确实在 msvc2019 上构建和运行得更好

如前所述，我记得问题跟踪器或其他沟通渠道中的其他此类帐户。 我不是在编造这个。

无论如何，应该始终尝试使用最新的工具链（在合理范围内，但 MSVC 2019 在这一点上已经成熟），除非有很好的理由不这样做。 此外，在过去几个月中，MSVC 2019 构建已经过广泛的实战测试，无论是由我、xavier2k6 或其他人提供，还是现在，最近由官方 GitHub Actions 工作流提供。 正如许多人试图告诉你的那样，50 MiB 不是一个好的理由。 不要让自己被那些痴迷超过 50 MiB 的人欺负！！ 我会亲自处理这些报告，您甚至不必看到它们。

升级到 MSVC2019 是否需要花费大量时间？ 这只是一个案例，如果不是，不是吗？ 因此，如果不是这个版本，那么肯定是下一个版本，因为版本通常相隔近几个月。

https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -711123971 只是一个主观报告，最有可能受到使用最新库和 qbt 代码的影响。 不是因为编译器。

升级到 MSVC2019 是否需要花费大量时间？ 这只是一个案例，如果不是，不是吗？ 因此，如果不是这个版本，那么肯定是下一个版本，因为版本通常相隔近几个月。

原因在这里给出https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -708055242

不要让自己被那些痴迷超过 50 MiB 的人欺负！！

我也不会让自己被那些痴迷于“最新和最伟大”的人欺负。 不同之处实际上是 68MB 的额外存储空间（我进行了本地静态构建）。 msvc2017 刚刚好！ 并且不需要额外的空间。

13505（评论）只是一个主观报告，最有可能受到使用最新库和 qbt 代码的影响。 不是因为编译器。

您对 MSVC 2019 根本没有提供任何好处的评论也是未经证实的说法。

我也不会让自己被那些痴迷于“最新和最伟大”的人欺负。 不同之处实际上是 68MB 的额外存储空间（我进行了本地静态构建）。 msvc2017 刚刚好！ 并且不需要额外的空间。

糟糕的复出。 没有人鼓吹最新的工具链是在“欺负”你。 坚持最新的工具链（再次，有理由）客观上是更好的政策，特别是当唯一反对它的论点是它产生更大的二进制文件时（我们不是为某些嵌入式平台开发）。 此外，使用与过去 _months_ 中大多数用户和贡献者一直在使用的 CI 不同的工具链发布版本并不是一个好政策。 最重要的是，很可能有一个相对简单的解决二进制膨胀的方法——让你的 50 MiB 朋友投入他们的精力来寻找问题，而不是仅仅抱怨 50 MiB，如果它让他们如此困扰的话。

（msvc2017 =>msvc2019）可以在另一个问题中讨论/争论/辩论等_WHEN_它变得有必要

一旦我们切换到 c++17，msvc2019 对我们来说将变得更加相关。

当Qt 需要 msvc2019和drop（windows 7/8/8.1 和 32 位支持）时，它也将在迁移到 Qt 6.0/6.1/6.2 时变得更加相关（我知道，这距离实现还有很长的路要走）

Qt 6.0 中的开发主机和目标

Qt 6.0 开发主机

Qt 6.0 开发目标

Qt 6.1 开发主机

Qt 6.1 开发目标

我不会进一步争论编译器。 我不同意你专门针对qbt。 一旦我们切换到 c++17，msvc2019 对我们来说将变得更加相关。

参考： https ://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -708094578

现在！，我们可以再一次在这里停车吗？

让我们推出 4.2.x/4.3.x！

（msvc2017 =>msvc2019）可以在另一个问题中讨论/争论/辩论等，当它变得必要时

现在！，我们可以再一次在这里停车吗？

让我们推出 4.2.x/4.3.x！

看，我想和其他人一样结束这件事，但如果没有别的，坦率地说，在包括你在内的其他所有人都在使用 MSVC 2019 进行测试时，在发布的最后一刻更改工具链是不负责任的。过去_months_。 从这个角度来看，我认为在这个版本中使用 MSVC 2019 是非常“必要的”。

就个人而言，我在这个游戏中有很多皮肤：如果出现任何问题，我将处理大多数类型为“夜间/CI 构建工作正常但发布没有”等错误报告等。是的，我知道我没有“必须”处理它。 但是我不希望项目在发布后因为可以避免的原因而被新问题淹没。 使用与 CI 相同或相似方式编译的库来完成发布已经够糟糕的了。

让我感到困惑的是，所有这一切，包括我投入到项目中的时间和精力以及管理问题跟踪器，并不比一个痴迷于 50 MiB 以上的人重要。 这些人到底是谁？ 他们为项目做了什么？

@FranciscoPombal我不会在这里对编译器进行任何进一步的讨论。 我的话是最后的。 这些版本将使用 msvc2017 制作。

如果我没记错的话，只有 Qt 5.15“正式”支持 msvc2019。 他们直到 Qt 5.15 才开始在 msvc2019 上运行 ci
由于前面提到的错误，他无论如何都无法使用 qt 5.15 发布。

看，我想和其他人一样结束这件事，但如果没有别的，坦率地说，在包括你在内的其他所有人都在使用 MSVC 2019 进行测试时，在发布的最后一刻更改工具链是不负责任的。最后几个月。 从这个角度来看，我认为在这个版本中使用 MSVC 2019 是非常“必要的”。

MSVC 2017 版本经过了整个 4.2.x 发布周期的实战测试，无论如何 msvc 2019 并没有太多新内容，而且 msvc 2017 仍然有主流发布周期，我不明白你为什么如此痴迷于“最新和最棒” .

@xavier2k6

此外，假设我们没有在下一个“大”版本之前修复额外的 50 MiB“问题”。 那么我们都会进行同样的讨论吗？ 我们会因此推迟升级到 Qt 6 吗？ 什么是/不比 50 MiB 更重要？ 我们只是把问题扫到地毯下，这是一个不好的先例。

提示，我几乎可以保证，根据我从其他人那里看到的意见，升级到 Qt6 的时间将比合理的时间长得多，原因有以下三个，可能更多，没有特别的顺序：额外50 MiBs 安装程序大小，保持对 Windows 7 的支持，保持对 32 位构建的支持。

@jagannatharjun Qt 5.15.1 使用 msvc2017 构建良好。 唯一相关的问题是选择标签时关闭上下文菜单。 IMO，这不是一个障碍。 Qt 5.15 带来了更好的 HiDPI 支持。

@FranciscoPombal我能理解您来自哪里，非常感谢您在这里的工作！

您提出的观点具有相关性，但不幸的是，我认为当前发布“新版本”的时间框架不允许进行这种讨论......（此时）

我不明白你为什么对“最新最好的”如此着迷。

客观上优越的政策不是“痴迷”。 我想你可以说我痴迷于不迎合其他愚蠢的痴迷。 但是，帮我一个忙，不要再把它投射到我身上了，是吗？ 它不会加强你的观点。

你们正在认真考虑保持合理的升级/现代化步伐作为“痴迷”，并且在安装程序中不超过 50 MiB。 耶稣他妈的。

@jagannatharjun Qt 5.15.1 使用 msvc2017 构建良好。 唯一相关的问题是选择标签时关闭上下文菜单。 IMO，这不是一个障碍。 Qt 5.15 带来了更好的 HiDPI 支持。

我同意，上下文菜单标签错误是不幸的，但 HiDPI 错误更加严重，并且随着时间的推移会产生更多报告。

@FranciscoPombal我能理解您来自哪里，非常感谢您在这里的工作！

不错的笑话。

您提出的观点具有相关性，但不幸的是，我认为当前发布“新版本”的时间框架不允许进行这种讨论......（此时）

我看我不能做任何其他事情。 那好吧。

@FranciscoPombal我能理解您来自哪里，非常感谢您在这里的工作！

不错的笑话。

@FranciscoPombal说真的？？ - 这不是开玩笑，我个人是真诚的！！！

您提出的观点具有相关性，但不幸的是，我认为当前发布“新版本”的时间框架不允许进行这种讨论......（此时）

我看我不能做任何其他事情。 那好吧。

不要把这种情况放在心上/放在心上......好吧
........喘口气
让您在项目中的部分努力至少可以通过新版本看到“主流公众”。 （目前它只能被像我这样来这里并参与/贡献/构建等的人看到

我刚刚推送了一个staging_v4_3_x分支。 它基本上是具有更新变更日志的大师。
请查看Changelog并告诉我是否有问题或我遗漏了什么。
@glassez

1. #13234 是否有任何面向用户的属性？ 应该在更改日志中的内容？ 例如“使用数百个种子提高会话的加载速度”。
2. #13395 的目的是什么。 它有什么作用？ 我应该在更改日志中包含一些内容吗？

稍后我会看看这个线程中提到的问题，这些问题可能会使一些提交不包括在发布中。 有消息通知你。

@sledgehammer999

另外，请在此过程中清理 PPA。 除18.04 、 20.04和20.10之外的 Ubuntu 版本已停产，因此应尽快删除针对这些版本的构建存档。

Ubuntu 14.04 和 16.04 不是 EOL。 你从哪里得到这份清单的？
https://wiki.ubuntu.com/Releases

@sledgehammer999看来你错过了https://github.com/qbittorrent/qBittorrent/pull/13188的更新日志

另外，您能否在更改日志中添加一条注释
“由于捆绑文件格式的更改，以前的主题捆绑包将无法在此版本中正常工作，请联系主题提供商进行修复。可以在此处阅读有关新格式的更多信息https://github.com/qbittorrent/ qBittorrent/wiki/How-to-use-custom-UI-themes ”或类似的东西。
实际上，这是因为https://github.com/qbittorrent/qBittorrent/pull/12755/files

我认为应该提到对 RC1_1 libtorrent 的支持已被放弃。

此外，如果有人想要更快的跟踪器通告速率或使用此版本的客户端退出速度较慢（与 4.2.x 相比），那么他们可能会尝试从高级设置中增加“最大并发 HTTP 通告”限制。

#13234 是否有任何面向用户的属性？ 应该在更改日志中的内容？ 例如“使用数百个种子提高会话的加载速度”。

抱歉，我不记得所有内容了……主要是内部改进。 也许 PR 描述的下一部分适合“面向用户的属性”：

它允许在某些情况下正确保存简历数据，例如在“丢失文件”状态下（尽管我们试图阻止更早完成此操作，但用户实际上可以在更改此类 torrent 的某些属性时执行此操作）。

#13395 的目的是什么。 它有什么作用？ 我应该在更改日志中包含一些内容吗？

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

我认为应该提到对 RC1_1 libtorrent 的支持已被放弃

👍

功能：添加对创建 v2 种子的支持（需要 libtorrent 2.0.x）（Chocobo1）

该死的！ qBittorrent 是否已经支持 libtorrent-2.0？ 为什么要按原样提及？ 我们确实已经谈过了。

另外，您能否在更改日志中添加一条注释
“由于捆绑文件格式的更改，以前的主题捆绑包将无法在此版本中正常工作，请联系主题提供商进行修复。可以在此处阅读有关新格式的更多信息https://github.com/qbittorrent/ qBittorrent/wiki/How-to-use-custom-UI-themes ”或类似的东西。
实际上，这是因为https://github.com/qbittorrent/qBittorrent/pull/12755/files

我想我会把它添加到网站的“新闻”部分。 在更改之外，在介绍性文本中。

我认为应该提到对 RC1_1 libtorrent 的支持已被放弃。

好的。

此外，如果有人想要更快的跟踪器通告速率或使用此版本的客户端退出速度较慢（与 4.2.x 相比），那么他们可能会尝试从高级设置中增加“最大并发 HTTP 通告”限制。

这应该在变更日志中作为一个项目提及吗？

该死的！ qBittorrent 是否已经支持 libtorrent-2.0？ 为什么要按原样提及？ 我们确实已经谈过了。

然后我将把这个项目移到v4.4.0发布条目下（不是 v4.3.0 更新日志的一部分）。 除非之前引入了官方的 libtorrent-2.0 支持。 那满意吗？

这是更新的变更日志： https ://github.com/qbittorrent/qBittorrent/commit/0302e8abbc545d13b7be51e011d2795a9bb3ea73

这应该在变更日志中作为一个项目提及吗？

我认为如果发布为新闻会更好。 由于每个种子拥有数千个种子/许多跟踪器的用户可能会注意到缓慢的发布行为。

再次更新： https ://github.com/qbittorrent/qBittorrent/commit/727dec97540091f891991113299fa38468e13885

公告：预计会有非常小的延迟。 由于通过电子邮件通知我的安全问题，我必须重新编译部分工具链。 详细信息将在发布后几天公布。 IMO，严重性可能很小，因为该漏洞利用需要恶意人员具有本地访问权限或已经在您的系统上运行恶意应用程序。 在这两种情况下，即使没有 qbt 的安全问题，你也已经被搞砸了。

Ubuntu 14.04 和 16.04 不是 EOL。 你从哪里得到这份清单的？

应该是写错了。 这对我们来说是 EOL，因为他们的 Qt 版本低于我们的最低要求。

好的。 我想现在一切都准备好了，我正在准备构建。 v4_3_x分支将与构建一起推送。

@sledgehammer999很抱歉迟到了评论，但请记住（在网站的新闻部分）提到自上一个版本以来存在许多 libtorrent 修复程序，包括已知的内存泄漏、速度问题Windows 上的缓存设置逻辑错误等。您可以查看 libtorrent 的 1.2.6-1.2.11（1.2.11 尚未正式发布，但已经有一些更改日志条目）以获取灵感并挑选最相关的条目。

出于好奇，将使用哪个 libtorrent 提交？

好的，最新的 git commit 一如既往。

@rrrevin

Ubuntu 14.04 和 16.04 不是 EOL。 你从哪里得到这份清单的？
https://wiki.ubuntu.com/Releases

应该是写错了。 这对我们来说是 EOL，因为他们的 Qt 版本低于我们的最低要求。

好吧，我想我的真正意思是“标准支持结束”，无论如何这真的很重要。 除此之外，只有付费企业才能获得支持。 从技术上讲，16.04 甚至还没有达到“标准支持结束”，但已经非常接近了。 无论如何，由于 qBittorrent 将最低要求的 Qt 版本提高到 5.9，它的 OOTB 支持在 2 年前左右就被放弃了。

@sledgehammer999还有一件小事：考虑在新闻中提及已知的标签上下文菜单小回归： https://github.com/qbittorrent/qBittorrent/issues/13492。

@sledgehammer999你没有在更新日志中记下我的许多 PR... https://github.com/qbittorrent/qBittorrent/pulls?q=is%3Apr+author%3AFranciscoPombal+is%3Aclosed+milestone%3A4.3.0

@FranciscoPombal我将您所有的 CMake PR 合并到一个条目中。 您的内部代码清理 PR 不能在 Changelog 中提及。 它应该包含面向用户的修复。 与@Chocobo1 的许多 PR 相同
如果我错过了具体的内容，请在下面提及。 我会等一会儿，因为我还在幕后做行政工作。

@sledgehammer999

它应该包含面向用户的修复。

好的，所以：

• --> https://github.com/qbittorrent/qBittorrent/pull/13042是面向用户的，因为它修复了嵌入式跟踪器中的公告错误。 <--

• https://github.com/qbittorrent/qBittorrent/pull/12086 、 https://github.com/qbittorrent/qBittorrent/pull/13109和https://github.com/qbittorrent/qBittorrent/pull/13439是非用户面临清理，所以我想这很好。

• https://github.com/qbittorrent/qBittorrent/pull/13288有点面向用户，我猜？ 现在用户可以从 CI 下载实验版本，这被认为是面向用户的吗？

• 其余的要么已经记入，与 CMake 改进相关（也已记入），要么与https://github.com/qbittorrent/qBittorrent/pull/13288 相关。

/offtopic（另一次）-也许非用户的清理应该包含在“其他”或新的“代码健康”部分？ 用户喜欢在更新日志中看到这类内容。

--> #13042 是面向用户的，因为它修复了嵌入式跟踪器中的公告错误。 <--

好的，对不起。 从提交标题中不清楚。 您能否建议一个适当的变更日志条目（供阅读它的用户使用）？

CI 更改通常与版本无关。

/offtopic（另一次）-也许非用户的清理应该包含在“其他”或新的“代码健康”部分？ 用户喜欢在更新日志中看到这类内容。

嗯，我将添加一个OTHER条目用于代码清理，这将归功于您和 @Chocobo1

我猜 13288 有点面向用户？ 现在用户可以从 CI 下载实验版本，这被认为是面向用户的吗？

IMO，可以在新闻中提及此类事情（在更改日志之外）。

IMO，可以在新闻中提及此类事情（在更改日志之外）。

我可以以某种方式在下载页面中填入一个“nightlies”链接......

〜@glassez〜 @ sledgehammer999

IMO，可以在新闻中提及此类事情（在更改日志之外）。

我可以以某种方式在下载页面中填入一个“nightlies”链接......

只要在新闻中提到 CI 的东西，在我们在可执行文件中进行基于 git 的版本控制之前，我会犹豫是否将“夜间”下载页面链接到更广泛的受众。 否则所有用户都会将所有不同的夜间版本报告为“4.x.xalpha1”，从而导致混淆。

可执行文件中基于 git 的版本控制。 否则所有用户都会将所有不同的夜间版本报告为“4.x.xalpha1”，从而导致混淆。

是的，这是一个正确的说法。

@sledgehammer999

您能否建议一个适当的变更日志条目（供阅读它的用户使用）？

“修复了嵌入式跟踪器中损坏的宣布逻辑在某些情况下导致失败的问题。”

CI 构建也可能用于恶意目的。 通过创建恶意 PR 并随后分发链接。
我建议不要在网站上链接这样的东西。

@an0n666

CI 构建也可能用于恶意目的。 通过创建恶意 PR 并随后分发链接。
我建议不要在网站上链接这样的东西。

这也是一个好点。 我想我最好开始专门针对夜间构建的工作流程，这些构建只从我之前讨论过的 master 构建。 然后我们将能够链接到夜间构建，而不必担心会发生这种事情。

发布完成。
PPA 将在明天清理。
几天后的安全问题详细信息。
几天后组织变革计划。

一如既往地感谢大家在这个发布周期中所做的贡献。