这个怎么样 - #10948？

到目前为止，master 上有一个已知问题（次要问题，但对某些人来说可能很烦人）：#11233

新的 4.2.0 测试版会使用 libtorrent 1.2.2 吗？

我使用的是 4.2.0 alpha，因为它发布了，我没有发现任何错误
我的电脑 --> i7-4790K + 16GB DDR3 + 128GB SSD + 500GB SSD + 4x1TB WD Blue HDD
Windows 10 专业版 x64 1903
1000/300 FTTB 互联网和每日流量：700-800GB 下降 / 1,1 - 1,5TB 上升 1300-1500 种子
所以我在等待新的测试版

有完整的更新日志吗？

还有#11076

有完整的更新日志吗？

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

有完整的更新日志吗？

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

所以 sledgehammer999 排除了一些合并的 PR 以供以后发布，
因为在 4.1.8 和 4.2.0alpha2 更新日志中没有提到合并的 PR ？

所以 sledgehammer999 排除了一些合并的 PR 以供以后发布，
因为在 4.1.8 和 4.2.0alpha2 更新日志中没有提到合并的 PR ？

不，他可能只是想念他们。 如果您可以指出这些 PR，以便将它们添加到变更日志中，那将会很有帮助。

我认为这是解决https://github.com/qbittorrent/qBittorrent/issues/10913和https://github.com/qbittorrent/qBittorrent/issues/11112的好时机，因为 libtorrent 1.2.2 刚刚发布此功能/修复：
add torrent_info constructor overloads to control torrent file limits

我只是想提高对这些问题的认识，希望其他人可以解决它们，现在我真的没有时间。

等不及 4.2 测试版了。 阿尔法运行顺利！

同样在这里。 4.2.0 alpha 2 运行没有错误。
我在等待第一个测试版

我不妨提一下，我也一直在运行 4.2.0 alpha 2，没有任何明显的错误。 我的操作系统是 Windows 10 版本 1803，64 位，以防万一。

不幸的是 - alpha1 和 alpha2 都存在问题（仍未重现......）

整数除以零异常 (0xC0000094)

11281

11332 ->更新：设法捕获堆栈跟踪并附加。

期待 libtorrent 1.2.2 的包含，尽管主要是#3833并且启用了#3913或至少可以选择在 GUI 中设置它（默认为“OFF”）

@glassez @Chocobo1 IIRC 在另一个问题中，我们确定 RC_1_2 快速恢复格式略有改变。 我不记得是哪一个，但有些字段不再保存到文件中。 这具有副作用，如果 RC_1_2 快速恢复加载到 RC_1_1 中，它将触发 torrent 重新检查。 所以基本上这对用户降级有意义。
在继续加载种子文件之前，当用户启动使用 RC_1_2 构建的 qbittorrent 实例时，我们是否应该发出某种警告？

@glassez @Chocobo1 IIRC 在另一个问题中，我们确定 RC_1_2 快速恢复格式略有改变。 我不记得是哪一个，但有些字段不再保存到文件中。 这具有副作用，如果 RC_1_2 快速恢复加载到 RC_1_1 中，它将触发 torrent 重新检查。 所以基本上这对用户降级有意义。
在继续加载种子文件之前，当用户启动使用 RC_1_2 构建的 qbittorrent 实例时，我们是否应该发出某种警告？

@sledgehammer999 - 你指的是 #10099 吗？

在继续加载种子文件之前，当用户启动使用 RC_1_2 构建的 qbittorrent 实例时，我们是否应该发出某种警告？

我认为至少我们应该在我们的网站上发布有关它的公告。 关于添加警告对话框，我对此没有强烈的感觉......不确定。

@xavier2k6 ：

你指的是#10099吗？

不， @sledgehammer999指的是 [ https://github.com/qbittorrent/qBittorrent/pull/11104 ]。

我们应该在我们的网站上发布有关它的公告。

：+1：

在继续加载种子文件之前，当用户启动使用 RC_1_2 构建的 qbittorrent 实例时，我们是否应该发出某种警告？

我不认为您可以轻松覆盖所有用户，因为他们中的许多人在没有 GUI 的情况下远程使用它。 即使在 GUI 的情况下，您可能不得不对启动顺序感到困惑……我认为这不值得。
一种想法是在更新对话框中添加警告。

一种想法是在更新对话框中添加警告。

更新对话框仅在 Windows 上可用，因此其他操作系统上的其他用户仍然无法获得它。

这具有副作用，如果 RC_1_2 快速恢复加载到 RC_1_1 中，它将触发 torrent 重新检查。 所以基本上这对用户降级有意义。
在继续加载种子文件之前，当用户启动使用 RC_1_2 构建的 qbittorrent 实例时，我们是否应该发出某种警告？

IMO 降级不应成为受支持的用例。 支持太麻烦了。 如果用户打算降级，他们至少应该备份他们的配置。 如果他们不这样做并在以后由于降级而遇到问题/不便，那就太糟糕了。

我在等待第一个 4.2.0 测试版
4.2.0 alpha 2 在这里仍然可以正常工作

@LordNyriox @ sledgehammer999它实际上是#10047 是我读过它的地方。
https://github.com/qbittorrent/qBittorrent/issues/10047#issuecomment -521656610

@sledgehammer999我在 alpha 版本中遇到的整数除以零问题已通过1.2和1.1 向后移植在 libtorrent 中得到解决，因此如果您可以发布带有 1.1/1.2 的新 alpha/beta 进行测试，那就太好了。

注意点：libtorrent升级到需要 C++17

在高级选项的 libtorrent 部分下：
“checking_mem_usage”已更改 ->“检查种子时内存不足”
根据文档中的 libtorrent“DEFAULT”，最大限制为“ 1024 ”。
#3213提高到“ 2048 ”，我说的对吗？
check_mem_usage

qbittorrent 的限制也会提高吗？

还：
在高级选项的 libtorrent 部分下：
根据文档中的 libtorrent“DEFAULT”，异步 I/O 线程设置为“ 4 ”。

如果我在下面正确阅读，它现在设置为“ 8 ”
aio_threads

更改日志中的错字：
- BUGFIX：Impove DownloadManager 代码（glassez）
-修正：进出口řOVE下载管理代码（glassez）
错别字

IMO 降级不应成为受支持的用例。 支持太麻烦了。 如果用户打算降级，他们至少应该备份他们的配置。 如果他们不这样做并在以后由于降级而遇到问题/不便，那就太糟糕了。

嗯不！
所以你从来没有遇到过有问题的版本（任何软件）并回到已知的工作版本？ 让我们不要在这里不切实际。

编辑：测试版现已发布。

现在更新到测试版。
在第一次打开时按预期检查所有种子。
这样做时似乎反应更灵敏。

编辑：高 CPU 使用率 & 实际上没有多次响应。已完成检查，但在第二天重新打开时，需要在启动时再次检查 70+...

几个小时后再次重新打开& 一些两次重新检查的文件必须再次重新检查？？？

EDIT2：以上已解决。

在 taskmanager/details->threads 下注意到显示270 & 似乎没有太大变化。
之前已经能够以 1000+ 的速度获得它...
线程（aio 线程）有问题吗？？

@ sledgehammer999 有什么理由不将 OpenSSL 更新到 1.1.1.d？
我想这是因为您仍然希望一次进行每个新的添加/更新.......

所以你从来没有遇到过有问题的版本（任何软件）并回到已知的工作版本？

是的。 但是，我的观点仍然成立。

顺便说一句，这也很重要： https :

@xavier2k6

“checking_mem_usage”已更改 ->“检查种子时内存不足”
根据文档中的 libtorrent“DEFAULT”，最大限制为“1024”。

3213 将其提升为“2048”，我说得对吗？

qbittorrent 的限制也会提高吗？

是和否。 正常的默认没有改变，改变的是一组特定的设置“高性能种子”，qbt 不使用（qbt 让用户直接设置值）。

根据文档中的 libtorrent“DEFAULT”，异步 I/O 线程设置为“4”。
如果我在下面正确阅读，它现在设置为“8”

和上面一样。

让我们不要太担心那些细微的差异:)

我认为 #11349 应该是一个阻塞问题，因为它使新主题支持有点无用，我会尝试尽快提交 PR

我认为 #11349 应该是一个阻塞问题，因为它使新主题支持有点无用

我认为不，因为主题支持仍然不完整/实验性，所以我们不应该在它的问题上如此努力地陈旧。

我认为 #11349 应该是一个阻塞问题，因为它使新主题支持有点无用

我认为不，因为主题支持仍然不完整/实验性，所以我们不应该在它的问题上如此努力地陈旧。

但是“qss”部分几乎完成，唯一的大问题是#11349（PR #11433），所以我认为至少 4.2 的第一个版本应该至少“几乎”工作 qss 主题支持。

@sledgehammer999
似乎你之前做了一个多余的 git 标签： https :

IMO，阻止发布的重点是影响核心功能或引入崩溃的问题。 可以在以后的版本中修复或改进的问题不应被视为阻塞。

@Chocobo1已删除。 显然git tag help没有显示关于标签的帮助:)

顺便说一句，有人在 Windows 上自己构建 openssl 1.1.x 吗？ 如果是， nmake test通过了所有测试？ 如果是，你能分享你如何构建它的完整说明吗？ 从头到尾，包括对配置文件的任何手动编辑。

@sledgehammer999
带有 OpenSSL 1.1.1.x 的旧 4.2.0 Alpha由@glassez 构建

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

顺便说一句，有人在 Windows 上自己构建 openssl 1.1.x 吗？ 如果是， nmake test通过了所有测试？ 如果是，你能分享你如何构建它的完整说明吗？ 从头到尾，包括对配置文件的任何手动编辑。

@sledgehammer999
带有 OpenSSL 1.1.1.x 的旧 4.2.0 Alpha由 @glassez 构建

第10047章（评论）

我希望 OpenSSL 1.1.1.x 包含在 4.2.0 中。 ：+1：

@ArcticGems因为它是 Qt 5.13.x 以后的要求。
Qt 5.13.0 在 Linux 和 Windows 上需要 OpenSSL 1.1.1 版本。
Qt 5.14.0 在 Linux 和 Windows 上需要 OpenSSL 1.1.1 版本。
对 OpenSSL 1.0.x 和 1.1.x 的支持结束/即将结束。

笔记

OpenSSL 1.0.2 目前只接收安全更新。 支持 1.0.2将于 2019 年 12 月 31 日结束。

对 1.1.0 的支持将于 2019 年 9 月 11 日结束，因此 1.1.0l 预计将成为
最后一个 1.1.0 版本。

这些版本的用户应该升级到 OpenSSL 1.1.1。

Qt 5.13.2 发布，修复了

我认为这是解决 #10913 和 #11112 的好时机，因为 libtorrent 1.2.2 刚刚发布了此功能/修复程序：
add torrent_info constructor overloads to control torrent file limits

我只是想提高对这些问题的认识，希望其他人可以解决它们，现在我真的没有时间。

11436 可以审查/实施 - 请参阅此处的@FranciscoPombal想法

在此处发布以供查看： https :

TL; DR：添加对在添加种子时更频繁地强制重新发布的支持/在跟踪器错误的情况下可能会用 1 块石头杀死 2 只鸟：

1. 解决一些“停滞”的报告
2. 使 qBitorrent 更适合赛车（这尤其有利于一些私人跟踪器观众）

它完全打破了 WebUI 中触摸屏（Surface、iPad、Phone）用户的列表...#11330

顺便说一句，有人在 Windows 上自己构建 openssl 1.1.x 吗？ 如果是， nmake test通过了所有测试？ 如果是，你能分享你如何构建它的完整说明吗？ 从头到尾，包括对配置文件的任何手动编辑。

@sledgehammer999我刚刚测试了从https://github.com/qbittorrent/qBittorrent/issues/11445#issuecomment -549781293在这里找到的构建

顺便说一句，有人在 Windows 上自己构建 openssl 1.1.x 吗？ 如果是， nmake test通过了所有测试？ 如果是，你能分享你如何构建它的完整说明吗？ 从头到尾，包括对配置文件的任何手动编辑。

我做到了。 我根本没有修改任何文件，只是“按原样”构建并运行测试……所以，其中一个测试失败了。 据我了解，它通过运行 openssl 可执行文件来测试当前 OpenSSL 构建支持的所有密码，但其中一项检查失败。 哪个是未知的。 我发现无法获得详细的测试输出，而且我不熟悉 Perl（用 Perl 编写的测试）。 我试图添加几个“printf”来测试，但这完全破坏了它，看起来像解析测试脚本输出的东西，我添加的打印语句破坏了这个解析器......
附上测试输出。 20-test_enc.t 测试中的 172 项检查仅失败了一项。
openssl-1.1.1-tests.txt

UPD：找到详细测试输出的方法。 失败的测试与 zlib 相关......但这很奇怪 - 下一个与 zlib 相关的测试通过了：

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.

将继续调查

UPD2：即使在 Linux 上测试也会失败！！ 所以，某种错误确实存在。 失败的原因是解密（解压缩）时读取（或写入）不完整 - 它仅将第一个缓冲区（命令行中指定的 157 个字节）写入输出文件，仅此而已。 100% 可重现，使用任何文件 ~200 字节大小（大于缓冲区大小）作为输入。

平@sledgehammer999

@Kolcha是的。 我收到同样的错误。 我选择在 openssl 上显式禁用 zlib 支持。 ( ./config WIN64a no-zlib )
从StackOverflow看来，启用它似乎不是一个好主意，因为它可能导致容易受到一类攻击。

你能在 Windows 上测试和验证最后一件事吗？ 做你通常的./config <options>但在发布nmake去编辑makefile 。 在那里找到CFLAGS只需将/O2更改/O1 。 那么在测试时，您是否会因名为test_test的测试而失败？ 我在 msvc2017 和 msvc2019 中都看到了这一点
这没什么大不了的，因为用/O2编译并没有太多损失，但是......

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

@ sledgehammer999，使用 msvc2019 使用/O1测试构建。 结果与您的相同 - test_test 失败。 我启用了详细输出（只是很好奇）以查看发生了什么，这非常奇怪：

    # 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]

所以改变 OpenSSL 的优化选项可能是个坏主意

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

从 StackOverflow 看来，启用它似乎不是一个好主意，因为它可能导致容易受到一类攻击。

是的，如果您不需要它，请禁用它。

openssl/openssl#8694

我从 4 月份开始报告，但该报告没有任何变动。 我现在看到他们在大约 20 小时前将其标记为已分类。 让我们希望它得到关注。 我将从这里添加新信息。

另请注意：这是 4.2.0 的最终游戏计划。 似乎 4.2.0 是稳定的，没有任何严重的错误待处理。 #11403 如果为 true 将被处理。 因此，鉴于此，我将发布基于 openssl 1.1.1d 和 libtorrent RC_1_2 的 RC（也许今天）。 同时，我将更新翻译文件的来源，以便翻译人员可以开始翻译新内容。
我们将等待 RC 和翻译人员，直到 11 月 16 日至 17 日周末。 在那个周末 v4.2.0 final 将发布并分支。

另请注意：这是 4.2.0 的最终游戏计划。 似乎 4.2.0 是稳定的，没有任何严重的错误待处理。 #11403 如果为 true 将被处理。 因此，鉴于此，我将发布基于 openssl 1.1.1d 和 libtorrent RC_1_2 的 RC（也许今天）。 同时，我将更新翻译文件的来源，以便翻译人员可以开始翻译新内容。
我们将等待 RC 和翻译人员，直到 11 月 16 日至 17 日周末。 在那个周末 v4.2.0 final 将发布并分支。

好的。 但是，我上面提到的东西有可能在发布之前得到解决吗？ 或者至少在 4.2.x 分支中。

这些问题不是阻塞问题。 没有什么能阻止我们将来在 4.2.x 分支中修复它们。

Qt 5.14将在月底发布......也许 4.2.0 Final 可以推出以配合......给 RC 一些额外的测试时间和翻译人员更多的时间来提交他们的更改...... ...也可能对 OpenSSL 测试问题/比解决方法有一个完整的修复。 （只是一个想法）

New_Features_in_Qt_5.14

图形用户界面

更新了高 DPI 支持。
添加了 QT_ENABLE_HIGHDPI_SCALING 环境变量，可根据显示 DPI 启用高 dpi 缩放。 替换 QT_AUTO_SCREEN_SCALE_FACTOR（现已弃用），并对应于 Qt::AA_EnableHighDpiScaling 应用程序属性。
添加 QGuiApplication::highDpiScaleFactorRoundingPolicy 和 QT_SCALE_FACTOR_ROUNDING_POLICY。 应用程序现在可以选择使用非整数比例因子。
QT_FONT_DPI 环境变量现在支持跨平台，用于使用特定 DPI 值进行开发和测试。

Qt网络

HTTP/2 配置 API

Qt 网络引擎

更新为基于 Chromium 77
用于控制 QWebEnginePage 生命周期的新 API

11448 可能需要一些调查。

也许可以把这个挤进去？ ;)

7743

带有 qBittorrent 4.2.0 beta 的 Windows 10 1903 Pro x64 工作正常
我有 1000/300mbit FTTB 互联网，我每天至少上传 1-1,4TB
我 24/7 全天候运行，没有任何问题
;)

今天我更新了翻译。 当我运行 lupdate 时，我看到了以下警告。 有人有时间解决吗？

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

今天我更新了翻译。 当我运行 lupdate 时，我看到了以下警告。 有人有时间解决吗？

公关#11476。

此 v3.2.1 里程碑项目的存根代码是否存在？：
https://github.com/qbittorrent/qBittorrent/issues/2193

@sledgehammer999 #11485 4.2.0 beta1 中的堆栈溢出

@sledgehammer999仅供参考
对于那些在 Windows 10 上遇到冻结/无响应的人 - 安装 Windows 10 build 1909（11 月更新）并反馈......build 1909 对我的测试机器有很大帮助。

那个RC在哪里？ 我预计决赛还有几个星期？

那个RC在哪里？ 我预计决赛还有几个星期？

我相信 RC 现在不会发生，因为翻译更新已经完成/正在完成......可能是错误的 - 这只是我的意见！
我预计决赛将在本周末/下月初举行，除非已经发布的 alpha/beta 有真正的阻止（有一些未解决的问题，但需要更多细节......堆栈跟踪等） ，如上所述 - 我更喜欢有一个更多的测试版本 (RC)，特别是在 libtorrent 1.2.x 下检查种子/fastresume 保存，因为自测试版以来在这个区域发生了变化 & 等待 Qt 5.14 <- 但是，唉，它也落后于它的发布时间表......

能否在 12 月发布 4.2.0 以及 Qt 5.14（应该在那时发布）和 Boost 1.72 于 12 月 11 日发布？？ 同样，这只是我的想法，但在那些即将发布的版本中可能没有任何重要的东西，开发人员可能需要延迟 4.2.0 版本，而 4.2.0 版本无法添加到 4.2.1 等中。

尽管这可能并不明显（尤其是对于远离开发的人而言），但在发布之前更改工具/库并不是一个好主意（我们已经有过悲惨的经历）。 这可能会带来一些新的问题。
IMO，最好使用经过测试的库版本进行发布（即开发人员在开发过程中使用了一段时间的库版本）。

虽然这可能不是很明显（尤其是对远离发展的人来说），

我希望这是一个一般性的观察并以此为指导-> 不是个人挖掘...lol

在发布之前更改工具/库不是一个好主意（我们已经有过悲伤的经历）。

4.1.6/OpenSSL??

IMO，最好使用经过测试的库版本进行发布（即开发人员在开发过程中使用了一段时间的库版本）。

这有点矛盾，因为 4.1.6 与 OpenSSL 1.1.1.x 一起发布，当时与 Qt 版本不完全兼容，我们都知道这是如何解决的。

不要误会我的意思，我没有对任何人进行个人攻击或批评，而只是提出建议和表达我的意见-> 这只是......意见......仅此而已。

对我来说，自 Alpha/Beta 甚至更早版本的测试期以来，4.2.0 有一些重大变化，我认为这些变化对 qbittorrent 的整体体验产生了影响。 （以一种好的方式）

我只是渴望努力帮助体验变得更好。

我一直对开发人员的工作表示感谢，并将继续这样做。

经过一些测试后，没有什么可以阻止新库的 .1 版本发布。 让我们不要再无故拖延发布。

考虑到 2016 年已修补支持 DHT over IPv6，是否可以添加对 #3601 的

经过一些测试后，没有什么可以阻止新库的 .1 版本发布。 让我们不要再无故拖延发布。

我同意一个带有新库的 .N 版本就足够了，而不是一个表演障碍。 （该选项只是我的一个意见）但是在“测试版”类别下仍然存在未解决的问题 -> 这些需要进行更多调查，如果需要，则需要花费时间来解决它们。

我自己的观点是“ RC ”应该像之前的计划一样在final之前发布，但现在看来我们是final的“GO”->完成后怎么样？

正如之前在上面的帖子中提到的：

11448 可能需要一些调查。

这个问题围绕着检查种子和丢失的文件......再次，自测试版以来对检查协议进行了进一步的调整，因此“ RC ”将有助于确认此问题是否至少已解决或将有助于进一步调试/调整。

此外，那些目前在 4.1 分支及更早版本中遇到检查问题/数据丢失的人可能会被要求测试“ RC ” - 有少数标记为此类。

另一个问题是我在“ Alpha ”和“ Beta ”中遇到的堆栈溢出 - 显然这个问题将更难根除并且不应该成为真正的表演障碍，但它已经在/在之前的其他版本中找到到 4.2.0。

调用“ RC ”的另一个原因是确认OpenSSL 1.1.1.x没有问题 - 我已经测试了与它集成的构建，但最好确保正如俗话所说。

再说一遍，这只是我的意见......

我刚刚发布了RC。 最终版本应该在月底的下周末。
我怀疑我会为那个使用 Qt 5.14。 只有最新的 openssl 和 libtorrent git。

@sledgehammer999感谢 RC！

考虑到 2016 年已修补支持 DHT over IPv6，是否可以添加对 #3601 的支持？ 谢谢

如果您使用使用 libtorrent 1.2.x 系列的 4.2.0 的 beta/RC 之一，它应该是开箱即用的。 请记住还要使用高级设置中的 IPv6 网络适配器。 虽然我不知道您是否真的会找到 IPv6 DHT 节点。 我不知道它们在这个时间点是否常见。

@ sledgehammer999 #11436 会进入 4.2.0 最终版本还是 4.2.N 版本？

tbh 对我来说https://github.com/qbittorrent/qBittorrent/issues/11233是一个阻塞问题，我可能会坚持 v4.1.9，因为我经常在“评论”字段中使用链接。

发布时是否有机会为安装程序提供实际的 Qbittorrent 图标，而不是 1990 年代的 nsis 图标？

tbh 对我来说 #11233 是一个阻塞问题，我可能会坚持 v4.1.9，因为我经常在“评论”字段中使用链接。

发布后几天修复。

@Chocobo1 @glassez在我们三个人之间快速投票。 我应该在这个周末发布最终版本还是另一个 RC？ 我投票给决赛。

@sledgehammer999 ，如果您使用 libtorrent-1.2 进行官方 qBittorrent v4.2 构建，您应该应用最新的与 fastresume 相关的修复程序。 他们已经被释放了吗？

如果您使用 libtorrent-1.2 进行官方 qBittorrent v4.2 构建，您应该应用最新的与 fastresume 相关的修复程序。 他们已经被释放了吗？

在我控制发布的 macOS/Windows 上，我将始终使用最新的 RC_1_2。 我对我们的 PPA 也是如此。 唯一没有它的用​​户群是使用其发行版存储库进行安装的用户。
PS：我认为关于跟踪器的 fastresume 修复是一个极端情况，不会影响实际用户。 有多少用户决定突然擦除所有跟踪器并将其留空？

好吧，那么我是为了最终版本。 我没有看到阻塞问题。
我希望你准备好在不久之后制作下一个版本？ 实践表明，在开始大规模使用后，我们可能会立即遇到一些缺点，因此应及时修复它们，不得无故拖延。

@ sledgehammer999 ，你能在 v4.2 中包含 #11538 吗？ 这是非常微不足道的。

@Chocobo1 @glassez在我们三个人之间快速投票。 我应该在这个周末发布最终版本还是另一个 RC？

我之前的回复： https :

@ sledgehammer999 ，你能在 v4.2 中包含 #11538 吗？ 这是非常微不足道的。

是的，但翻译人员没有足够的时间来翻译它，不过是个小问题。

但是翻译人员没有足够的时间来翻译它，虽然是小问题。

我认为在这种特殊情况下这是可以接受的。

我投票给 RC2 因为我想在最终 4.2.0 之前检查匈牙利语翻译

我投票给 RC2 因为我想在最终 4.2.0 之前检查匈牙利语翻译

可以在 4.2.n 版本中修复/更新

11448 可以在恢复/检查 PR 中修复 - 用户关闭/不愿意帮助进一步调试。

11123 和 #11485 仍处于打开状态，但目前无法重现（如果有的话）——调试正在进行中。

“CTP 到最终”

题外话：GUI/选项等中的暂时不响应/冻结问题可能归结于传输列表刷新率？！，我经历了这一点并提高了我的刷新列表率，这有帮助......从 1000 毫秒 -> 5000 毫秒（取决于种子的数量，必须相应地调整）

也未选中“使用交替行颜色”

GUI/选项等中的暂时不响应/冻结问题可能与传输列表刷新率有关？！，我遇到了这个问题并提高了我的刷新列表率，它帮助......从 1000 毫秒 -> 5000 毫秒（取决于数量）的种子，必须相应地调整）

只是好奇，你有多少种子？ v4.2.0 应该比以前的版本性能好一点。

目前有375个。

传输列表如何更新/呈现 - qpaint 通过 opengl 或 qmodelindex 等？

公告：3 种操作系统的工具链构建尚未完成。 所以我希望明天发布。

公告2：我已经完成了所有的构建。 剩下的就是对构建和上传它们进行一些基本的质量控制（测试）。 但现在对我来说太晚了（凌晨 3 点）。 我会在睡觉和工作后几个小时内完成。
PS： @glassez @Chocobo1 v4.2.0 已经在本地分支了，但是我还没有推送那个分支。 我会推迟，直到构建上线。 master 分支已经更新，可以继续合并 PR，不影响发布。

嗨，分支后提交更改的政策是什么？
它会只出现在 4.3.0 中还是可以在 4.2.1 中出现？

@j1warren ：

分支后提交更改的政策是什么？

从历史上看，就在每个版本构建之前，所有提交都从 qBittorrent master分支中挑选到相关的发布分支。

@glassez一直在游说将此发布政策永久更改为以后4.1.x发布的版本（在此情况下，master 的 PR 会根据具体情况添加到发布分支中），但是 AFAIK， @sledgehammer999一直坚持对4.2.x继续使用旧的发布方式。

4.2.0 最终发布。
下载页面

恭喜发布。 知道什么时候会被推送到PPA吗？

发布是在几分钟前完成的。
花了一段时间，因为：win32 build 在启动时崩溃了。 这是 zlib v1.2.11 的错。 在网上搜索后发现，在过去的几年里，我收到的报告也发生了类似的崩溃。 这一切都源于使用 asm 优化的构建。 事实证明，作者建议使用非 asm 优化的，因为至少对于 Windows，asm 代码位于contrib文件夹中，并且它不是官方的。 它不是由他维护的，所以它可能会坏掉。 因此，我选择重建 64 位工具链和 32 位工具链，以防止出现随机和无法解释的崩溃。 （并且为了遵循作者的建议）。

@j1warren从master开始的几乎所有东西都被精心挑选到了稳定的分支中。 破坏性更改例外。 所以是的，您的 PR 将出现在下一个版本中。

@zachberger稍等一下。 在每个版本中，我都必须更新很多内容以公开反映该版本， @xavier2k6 抢先一步。 在任何情况下，我都会将 PPA 指向新分支，它应该开始构建新包。 几个小时后再回来看看。

更新安装程序图标？ 它应该是 qBT 图标，而不是几十年前的一些低分辨率、抗锯齿效果不佳的图标？

https://gyazo.com/0df814946c7870a0344deae368ee3638

更新安装程序图标？ 它应该是 qBT 图标，而不是几十年前的一些低分辨率、抗锯齿效果不佳的图标？

请提交另一个问题。