@sledgehammer999 вы должны прочитать это => https://github.com/orgs/qbittorrent/teams/bug-handlers/discussions/5

К счастью, у меня нет вируса (и я надеюсь, что таковым и останусь).

Я рад лично за тебя.

Но мне очень грустно от текущего положения дел в проекте (и я не единственный, кто думает так же). Время для изменений имеет решающее значение. Так что вы должны либо перестроить управление/сопровождение проекта, либо явно заявить, что это только ваша личная игрушка, чтобы ни у кого больше не было ложных надежд.

Есть ли какие-либо коммиты, которые должны быть исключены?

Я не думаю, что имеет смысл пропускать какие-либо изменения сейчас.

В любом случае, новый релиз давно назрел.

Слишком.

Должен ли я, как обычно, переносить все новые основные коммиты в ветку v4_2_x?

Почему v4.2.x? Изменений для v4.3 более чем достаточно!
Кроме того, вы можете просто создать ветку v4_3_x поверх текущего мастера, вместо того, чтобы делать эту ненужную работу, «выбирая» коммиты один за другим.

Я только что закончил просматривать коммиты от предыдущего выпуска до последнего мастера. (в основном заголовки коммитов и PR-описания)

Почему v4.2.x? Изменений для v4.3 более чем достаточно!

Да. Существует тонна коммитов. И поскольку libtorrent 1.1.x был удален, он, безусловно, требует версии 4.3.x. (И v4.4.x для libtorrent 2.0.x и c++17!!!)
Я создам новый PR для предстоящего журнала изменений как можно скорее.

Об управлении проектом: мы обсудим это после выходных / предстоящего релиза.

@sledgehammer999

Рад, что ты вернулся и что все в порядке.

Должен ли я, как обычно, переносить все новые основные коммиты в ветку v4_2_x? Есть ли какие-либо коммиты, которые должны быть исключены?

Я равнодушен к предложению маркировать новую версию 4.3.x. Вам и другим решать.

Все коммиты хороши, насколько я знаю. Тем не менее, множество очень важных исправлений также было объединено с libtorrent, поэтому важно использовать последнюю возможную версию RC_1_2 для этого нового выпуска.

Уже было несколько коммитов, касающихся поддержки BitTorrent V2. Тем не менее, я ожидаю, что этот выпуск будет собран с последней версией libtorrent RC_1_2 , как упоминалось выше, поэтому большинство пользователей не увидят ничего из этого на практике. Таким образом, я бы поместил примечание в журнал изменений, объясняющее это, чтобы у пользователей не было ложных надежд, когда они читают записи, связанные с BitTorrent V2.

Я обновил свой локальный набор инструментов. Бэкпорт/журнал изменений/минимальное тестирование займет некоторое время. Но я думаю, что эти выходные — достижимая цель, в зависимости от размера изменений.

Не могли бы вы предоставить подробную информацию об этом? Я предполагаю, что у вас самая последняя версия MSVC 2019, и я _надеюсь_, что вы используете vcpkg или аналогичный для зависимостей - меньше шансов странных ошибок из-за небольших несоответствий в том, как все построено, и больше воспроизводимости. Вы можете проверить новый GitHub Actions CI для вдохновения. Также не забудьте использовать CMake для сборки на этот раз, она стала новой системой сборки по умолчанию.

Об управлении проектом: мы обсудим это после выходных / предстоящего релиза.

Хорошо, но скорее раньше, чем позже, пожалуйста. И мы должны продолжить обсуждение автоматизации процесса выпуска, чтобы даже упаковка могла выполняться автоматически.

@sledgehammer999

Кроме того, пожалуйста, очистите PPA в процессе. Выпуски Ubuntu, отличные от 18.04 , 20.04 и 20.10 , являются EOL, поэтому архивы для сборок, предназначенных для этих версий, должны быть удалены как можно скорее.

поэтому важно использовать самую последнюю возможную версию RC_1_2 для этого нового выпуска.

Это само собой разумеется.
Qt 15.1, openssl 1.1.1h, буст 1.74

RC_2_0 еще не будет использоваться. Не обошлось и без пары официальных бета-релизов.

Я предполагаю, что у вас самая последняя версия MSVC 2019, и я надеюсь, что вы используете vcpkg

Нет, я все еще остаюсь с msvc2017 для этого выпуска. В прошлый раз, когда я проверял msvc2019, он создал очень большой файл .pdb для qbt. Я проверю еще раз позже, но не для этого выпуска.
Остальные зависимости строятся так, как я всегда это делал. Более или менее описано здесь: https://github.com/qbittorrent/qBittorrent/wiki/Compiling-with-MSVC-2019- (static-linkage)

Также не забудьте использовать CMake для сборки на этот раз, она стала новой системой сборки по умолчанию .

Видимо, я пропустил это в журнале git. Я немного расстроен, но я не могу возражать, поскольку всем остальным удобнее использовать cmake, чем autotools/qmake.
Однако пока я буду продолжать использовать autotools/qmake для релиза. У меня нет времени знакомиться с cmake к релизу.

Я посмотрю, что делать с PPA, хотя они никому не вредят.

@ sledgehammer999 Я знаю, что вы не хотите, чтобы обычные пользователи комментировали здесь, поэтому приношу свои извинения ...... Я делал здесь сборки Windows с целью устранения проблем / ошибок и т. Д.

Я компилирую с помощью MSVC 2019, исполняемые файлы qBittorrent обычно составляют около 27 МБ, а .pdb — 180 МБ.

Вы думали об использовании /pdbstripped ?

Я компилирую с помощью MSVC 2019, исполняемые файлы qBittorrent обычно составляют около 27 МБ, а .pdb — 180 МБ.

Сравните с msvc2017 и текущим мастером: 24,4 МБ exe и 98,1 МБ pdb. Как я уже сказал, pdb очень большой по сравнению с msvc2017.

Также я не думаю, что нам нужен /pdbstripped. Это, вероятно, даст менее полезные следы при сбое программы.

Также я не думаю, что нам нужен /pdbstripped. Это, вероятно, даст менее полезные следы при сбое программы.

/PDBCompress ?

@sledgehammer999

Автоматизированные сборки CI, в которых используется CMake + последняя версия MSVC 2019 + vcpkg (https://github.com/qbittorrent/qBittorrent/actions), занимают 57 МБ (исполняемый файл) + 122 МБ (pdb).

Нет, я все еще остаюсь с msvc2017 для этого выпуска. В прошлый раз, когда я проверял msvc2019, он создал очень большой файл .pdb для qbt. Я проверю еще раз позже, но не для этого выпуска.

Это не уважительная причина, ИМО. MSVC 2019 содержит множество исправлений. Это (конец) 2020 года. Никто не заботится о дополнительном размере \ ~ 50 МБ (а если они это сделают, очень плохо, лол). Мы можем выяснить это позже, если что-то раздувает pdb/executable, но сейчас все работает, и дополнительные \~50 МБ — это компромисс, который я бы сделал в любой день недели для гораздо более свежей цепочки инструментов.

Также я не думаю, что нам нужен /pdbstripped. Это, вероятно, даст менее полезные следы при сбое программы.

:+1:, но это может быть тщательно исследовано в будущем.

Остальные зависимости строятся так, как я всегда это делал. Более или менее описано здесь: https://github.com/qbittorrent/qBittorrent/wiki/Compiling-with-MSVC-2019- (static-linkage)

Видимо, я пропустил это в журнале git. Я немного расстроен, но я не могу возражать, поскольку всем остальным удобнее использовать cmake, чем autotools/qmake.
Однако пока я буду продолжать использовать autotools/qmake для релиза. У меня нет времени знакомиться с cmake к релизу.

:-1:, это не тот способ, которым большинство людей тестировали qBittorrent в течение последних месяцев на Windows. Многие люди использовали сборки из моей ветки CI (CMake + vcpkg), а теперь и собственного раздела Actions репозитория. Я бы сказал, что весьма вероятно, что мы будем наблюдать необъяснимые регрессии, просто связанные с различиями в процессе сборки, если вы сделаете это.

@sledgehammer999 Я не хочу больше добавлять «блокировщики» перед релизом, но, по крайней мере, я подожду, пока это приземлится, так как оно в основном готово: https://github.com/qbittorrent/qBittorrent/pull/13499

Изменение значения по умолчанию для потоков асинхронного ввода-вывода будет полезно для многих пользователей.

Я не хочу дисс msvc2019, но я думаю, что вы немного перестарались, считая все новое лучше. Это не всегда так. И да, дополнительные 50 МБ для клиента bt — это большое дело. Это ненужное раздувание без каких-либо измеримых преимуществ (например, программа не стала в 1,5 раза быстрее).

Наконец, о системах сборки: если мы видим регресс только из-за изменения системы сборки, значит, с кодом что-то серьезно не так. Вещи не должны быть такими хрупкими.

13499 выходит за рамки, поскольку речь идет об опции libtorrent 2.0.x, которая еще не установлена ​​по умолчанию. Окончательная стрижка будет сделана в выходные.

@sledgehammer999

Я не хочу дисс msvc2019, но я думаю, что вы немного перестарались, считая все новое лучше. Это не всегда так.
И да, дополнительные 50 МБ для клиента bt — это большое дело. Это ненужное раздувание без каких-либо измеримых преимуществ (например, программа не стала в 1,5 раза быстрее).

Пожалуйста, не отбрасывайте мои аргументы как «новое = лучше». И я думаю, что вы немного «переборщили», придерживаясь худшего набора инструментов для 50 МБ. Конечно, вы никогда (или очень редко) не увидите 1,5-кратного ускорения при обновлении набора инструментов. Но это нереальная планка. С более поздней цепочкой инструментов может не быть ускорения в 1,5 раза, но всегда есть небольшие улучшения производительности, лучшая языковая поддержка, улучшенная генерация кода (иногда приводящая к меньшему количеству ошибок), ... В Интернете есть множество ресурсов, документирующих улучшения в MSVC 2019.

Опять же, я согласен с тем, что мы должны сократить эти дополнительные 50 МБ, если это вообще возможно, но я считаю, что если мы не сможем сделать это к следующему выпуску (или когда-либо!), _это нормально_. Кроме того, нет никакого намека на то, что это будет повторяться с каждым релизом снова (в этом случае меня бы это тоже раздражало). Это явно разовая проблема. Как пользователь, я бы не хотел слышать «вот твой двоичный файл худшего качества, но, по крайней мере, мы сэкономили тебе 50 МБ, братан». 50 МБ в настоящее время является ошибкой округления (во всяком случае, для настольных программ; конечно, во встраиваемом мире это не так). Извините, но вы просто ошибаетесь, если думаете иначе.

Наконец, о системах сборки: если мы видим регресс только из-за изменения системы сборки, значит, с кодом что-то серьезно не так. Вещи не должны быть такими хрупкими.

Не обязательно. Что-то может быть серьезно не так с самой системой сборки. См. предыдущее состояние системы сборки CMake до моего PR капитального ремонта. До этого сборка с помощью CMake вызывала довольно много ошибок. Некоторые (иногда серьезные!) проблемы действительно возникают из-за неправильных/плохих систем сборки и рецептов сборки. Независимо от того, насколько надежен ваш код, если вы создадите его неправильно, он сломается, иногда очень впечатляющим, но трудно диагностируемым образом.

13499 выходит за рамки, поскольку речь идет об опции libtorrent 2.0.x, которая еще не установлена ​​по умолчанию. Окончательная стрижка будет сделана в выходные.

Пожалуйста, смотрите остальную часть обсуждения. Этот PR также фактически изменяет количество потоков асинхронного ввода-вывода по умолчанию, так что по умолчанию при сборке против libtorrent 1.2.x также используются как минимум 2 потока хеширования. Это приводит к очень значительному приросту производительности для пользователей SSD (на самом деле, более чем в 1,5 раза, хех), а также дает очень незначительный прирост для пользователей жестких дисков.

@sledgehammer999

Вот некоторая помощь, чтобы вы начали:

• новый учебник по сборке с помощью CMake статически в Windows: 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, где найти файлы конфигурации для пакетов, например -DLibtorrentRasterbar_DIR=C:\path\to\libtorrent-install-dir\lib\cmake\LibtorrentRasterbar . Если вы сомневаетесь, вы можете просто запустить configure до тех пор, пока он не завершится успешно, исправляя каждое сообщение об ошибке для каждого пакета по одному по мере их появления, поскольку сообщения об ошибках достаточно полезны, чтобы вы всегда могли понять и выяснить, что вам нужно добавить. следующий.

Я не собираюсь дальше спорить о компиляторах. Я не согласен с вами конкретно по qbt. msvc2019 станет для нас гораздо более актуальным, когда мы перейдем на c++17. Наконец, для пользователя bt-клиента все, что его волнует, это может ли клиент достичь максимальной скорости вниз/вверх. Это показатель для «лучшего» или «худшего» качества бинарного файла. msvc2017 достигает этого без лишних наворотов. --Я придерживаюсь своего мнения, пока не переделаю свои сборки с помощью msvc2019--

например -DLibtorrentRasterbar_DIR=C:\path\to\libtorrent-install-dir\lib\cmake\LibtorrentRasterbar

Имеет ли значение, как пакет собирается/устанавливается? В настоящее время у меня нет папки cmake под lib для любого из boost, libtorrent, openssl. Только для кт.
PS: boost и libtorrent собраны с использованием b2. Openssl с помощью их скрипта configure.

@sledgehammer999

Единственное требование — собрать libtorrent с помощью CMake, IIRC. Все остальные пакеты либо генерируют необходимые файлы конфигурации по умолчанию, либо каким-то образом поддерживаются 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 МБ (а если они это сделают, очень плохо, лол).

Моим двум основным компьютерам 9 и 12 лет (правда, недавно я их усовершенствовал, установив SSD в качестве системных дисков). Многие используют даже более старое оборудование. Это не потому, что нам это нравится. У нас просто нет финансовых/других возможностей обновлять его каждые 2-3 года. Если вы не способны нас понять, это еще не дает вам права насмехаться над нами.

PS Впрочем, еще 10 лет назад я бы так не парился по поводу этих 50 мегабайт.

@an0n666 @ sledgehammer999 @glassez

Я согласен с кувалдой999.
Меньший двоичный файл всегда лучше. Специально учитывая послужной список прошлых релизов.
У многих по-прежнему медленный интернет... также веб-сайт, обслуживающий двоичные файлы, может быть медленным для некоторых пользователей в зависимости от местоположения.
В таких случаях небольшой двоичный файл обеспечивает более быструю загрузку. Люди могут разочароваться в обновлении, если они подозревают ненужное вредоносное ПО.

Да ладно, загрузка приложения является единовременной. Даже при 10 Мбит/с дополнительные 50 МБ — это всего лишь дополнительные 50 секунд. Если этих людей это так беспокоит, им лучше прийти сюда и помочь решить проблему самим. Не позволяйте себе манипулировать обсессивно-компульсивными людьми, которые жалуются на 50 МБ. Из-за этого они хотят вернуться на UT 2.2.1? Отлично. Даже в Сомали вы можете получить в среднем 10 Мбит/с: https://www.speedtest.net/global-index , и я сомневаюсь, что клиент BitTorrent является главной заботой большинства коренных сомалийцев. Сборки обслуживаются как Fosshub, так и Sourceforge, которые вряд ли когда-либо станут узким местом, если только Ким Кардашьян не скажет всем своим поклонникам загрузить qBittorrent или что-то в этом роде.

Также,

Меньший двоичный файл всегда лучше. Специально учитывая послужной список прошлых релизов.

Нужна цитата. Где корреляция между «лучшим послужным списком» и «меньшим размером двоичного файла»? Лучший послужной список чего? Представление? Надежность?

система сборки по умолчанию чего?

он даже объявил qmake/autotools устаревшим https://github.com/qbittorrent/qBittorrent/wiki

Этот произвол начинает реально бесить!

Ух ты! Так что это не фактическое решение! В конце концов, я не чувствую себя обделенным.

Мы согласились, что за системой сборки CMake будущее. Было бы ошибкой продолжать поддерживать две системы сборки, как я неоднократно заявлял ранее. Это даже упоминается в недавних статьях: https://github.com/qbittorrent/qBittorrent/pull/13509#issuecomment -708072078.

Говоря о вирусах: посмотрите на дублирование усилий, которые мы прилагаем из-за поддержки двух систем сборки. Посмотрите на несколько файлов автоинструментов, которые у нас есть в репозитории.

Пожалуйста, не отвлекайте @sledgehammer999 бесполезными разговорами о разных сборочных инструментах, системах сборки и т.д. Пусть следующий релиз будет сделан как обычно - так будет быстрее и надежнее.

Еще одна атака, возможно, на самого активного члена этого репозитория за последние несколько месяцев, внесшего решающий вклад, особенно в области систем сборки, инструментов и т. д. Новые сборки и модификации системы сборки _более_ надежны. Насколько я помню, были даже случаи, когда проблемы исчезали просто при сборке по новому методу. Благодаря моим усилиям теперь мы можем гораздо быстрее получать в руки пользователей более надежные сборки. Это, конечно, НЕ бесполезно. Я планирую и дальше улучшать это, вплоть до официального релиза, но не рассчитывайте на меня, если вы будете продолжать так унижать мое участие.

Я не отвлекаю его, я знакомлю его с важными событиями последних месяцев. На нем лежит обязанность наверстать упущенное.
Теперь, когда сани вернулись, я, как и все остальные, хочу вынести сборку за дверь, но я хочу сделать это _правильно_. Возвращение саней не должно означать, что мы должны вернуться к нашим старым привычкам (даже для этого релиза кажется компромиссом), это должно означать, что мы можем развиваться _быстрее_, чтобы достичь того места, в котором мы хотим быть.

Нам нужно успеть решить организационные вопросы, чтобы мы смогли удержать проект на плаву, невзирая на то, что один из его участников пропадет надолго.

Частично проблема заключается в том, чтобы полагаться на одного человека для ручного создания сборок с устаревшей и менее ремонтопригодной системой сборки, прыгая через обручи только из-за 50 МБ (это можно решить позже) и т. д. Учтите тот факт, что мы отклоняемся от toolchain мы используем в нашем 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 МБ на настольных компьютерах/ноутбуках в наши дни (читай: последние 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

Извините за массовый пинг, но этот тоже кажется довольно важным и, к сожалению, сейчас немного беспорядок (в этот момент я также не понимаю, в чем проблема на самом деле): https://github.com/ qbittorrent/qBittorrent/issues/13389. Может быть, кто-то из вас сможет пролить на это новый свет?

Одно можно сказать наверняка; Я бы не хотел рисковать всеми настройками *arr с первым релизом 4.3.x.

этот также кажется довольно важным и, к сожалению, сейчас немного беспорядок (я также не понимаю, в чем проблема на самом деле): # 13389. Может быть, кто-то из вас сможет пролить на это новый свет?

Одно можно сказать наверняка; Я бы не хотел рисковать всеми настройками *arr с первым релизом 4.3.x.

Пожалуйста, не начинайте сходить с ума в самом конце. В чем проблема? (Кроме проблем с пониманием логики приложения.) Мы ведь не меняли связанный код? Я конечно не читал всю ветку. Если есть явное свидетельство ошибки в приложении, пожалуйста, укажите мне на конкретный комментарий.

@glassez

Пожалуйста, не начинайте сходить с ума в самом конце. В чем проблема? (Кроме проблем с пониманием логики приложения.) Мы ведь не меняли связанный код? Я конечно не читал всю ветку. Если есть явное свидетельство ошибки в приложении, пожалуйста, укажите мне на конкретный комментарий.

Никто не волнуется, нам просто нужно знать о возможных последствиях. Смысл в том, чтобы кто-то другой прочитал ветку внимательно и с ясной головой. Раньше, когда я пытался решить эту проблему, я не мог быть уверен, была ли это законная регрессия или пользовательское искажение недавнего изменения, или недавнее изменение формулировки выявило неожиданный дефект или что-то в этом роде. Это усугубляется тем фактом, что я никогда не пользовался программами *arr , но я знаю, что многие люди так и делают. Несмотря на это, вот исходные отчеты в репозиториях *arr : https://github.com/Radarr/Radarr/issues/5032 https://github.com/Sonarr/Sonarr/issues/3968 , если вы хочу взглянуть.

Привет ребята,

Я только что заметил, что кто-то упомянул FOSSHUB в предыдущем комментарии. Прочитал ветку и хочу сказать. Предполагая, что qBittorrent будет иметь около 50 МБ, для нас это не имеет значения. То же самое с любым всплеском трафика, кто-то упомянул Ким Кардашьян. Пожалуйста, попросите ее порекомендовать qBittorrent; Я уверен, что мы не упадем. Мы можем поглотить этот трафик. Например, всякий раз, когда выпускается новый qBittorrent, мы наблюдаем тысячи запросов на обновление в секунду.

Я пытаюсь сказать, что вы не должны беспокоиться об этом.

Спасибо!

мои 1,5 цента, по какой-то причине он строится и работает лучше на msvc2019
50 МБ дискового пространства - это абсолютно ничего в 2020 году, если ваша система НАСТОЛЬКО ограничена, то вы все равно используете более легкий клиент или qbt-cli.

никогда не откладывайте обновление вашего проекта до последней и лучшей версии, когда это можно сделать без ошибок, чем дольше вы ждете, тем больше вы рискуете отстать и застрять на мертвом неподдерживаемом компиляторе никому не доставляет удовольствия

Я думаю, что sledge имел в виду такие проблемы, которые открываются даже после увеличения размера установщика всего на 12 МБ.
https://github.com/qbittorrent/qBittorrent/issues/12247

Таким образом, это даже не 50 МБ, а только 12 МБ, которые люди тратят на создание заявки на выпуск.

@ sledgehammer999 «ЕСЛИ» вы собираетесь использовать Qt 5.15.0/5.15.1 в следующем выпуске, обратите внимание на (контекстное меню закрывается после выбора одного тега) #13492

Проще говоря, я думаю, что если он будет помечен как 4.3, никто не будет жаловаться на то, что установщик стал больше, это, безусловно, ожидаемо! Честно говоря, сохранение устаревших наборов инструментов кажется подходящим представлением процесса выпуска qBittorrent.

Взволнованный тем, что, наконец, это произойдет, я почти потерял надежду увидеть что-то в этом году.

Я думаю, что sledge имел в виду такие проблемы, которые открываются даже после увеличения размера установщика всего на 12 МБ.

12247

>

Таким образом, это даже не 50 МБ, а только 12 МБ, которые люди тратят на создание заявки на выпуск.

Так? Единственным подходящим ответом для таких билетов будет «как угодно, чувак». Я не понимаю навязчивой идеи прогибаться назад для этих людей. Как я уже сказал в https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -708436739, мы, конечно, всегда будем делать все возможное, чтобы предотвратить такое увеличение размера, но мы не должны жертвовать ничем другим только ради 50 MiB, и если кого-то это беспокоит, они могут прийти сюда и исправить это сами.

мы не должны жертвовать ничем другим

Извините, но я действительно не понимаю, чем мы жертвуем, не переходя на последний и самый лучший (сомнительный) компилятор. Нет ничего ощутимого в переходе на последний компилятор. Не то чтобы msvc2017 — древний компилятор.

@sledgehammer999

Извините, но я действительно не понимаю, чем мы жертвуем, не переходя на последний и самый лучший (сомнительный) компилятор. Нет ничего ощутимого в переходе на последний компилятор. Не то чтобы msvc2017 — древний компилятор.

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

мои 1,5 цента, по какой-то причине он строится и работает лучше на msvc2019

Как упоминалось ранее, я помню другие подобные сообщения об этом в системе отслеживания проблем или других каналах связи. Я не выдумываю.

Несмотря на это, всегда следует пытаться использовать новейшую цепочку инструментов (в пределах разумного, но на данный момент MSVC 2019 является зрелой), если только нет очень веской причины не делать этого. Кроме того, за последние несколько месяцев сборки MSVC 2019 были тщательно протестированы в боевых условиях, либо предоставлены мной, xavier2k6 или другими, либо теперь, совсем недавно, с официальным рабочим процессом GitHub Actions. 50 МБ — это не очень хорошая причина, как многие пытаются вам сказать. Не позволяйте запугивать себя тем, кто одержим более 50 МБ!! Я лично позабочусь об этих отчетах, вам даже не придется их видеть.

Обновление до MSVC2019 требует много времени? Это просто тот случай, когда нет, не так ли? Так что если не этот релиз, то уж точно следующий, учитывая, что релизы, как правило, выходят с разницей почти в несколько месяцев.

https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -711123971 — это только один субъективный отчет, на который, скорее всего, повлияло использование последних библиотек и кода qbt. Не из-за компилятора.

Обновление до MSVC2019 требует много времени? Это просто тот случай, когда нет, не так ли? Так что если не этот релиз, то уж точно следующий, учитывая, что релизы, как правило, выходят с разницей почти в несколько месяцев.

причина указана здесь https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -708055242

Не позволяйте запугивать себя тем, кто одержим более 50 МБ!!

Я также не позволю запугивать себя теми, кто одержим «новейшими и лучшими». И разница на самом деле составляет 68 МБ дополнительного хранилища (я делал локальные статические сборки). msvc2017 просто работает! и не требует дополнительного места.

13505 (комментарий) — это только один субъективный отчет, на который, скорее всего, повлияло использование последних библиотек и кода qbt. Не из-за компилятора.

И ваши комментарии о том, что MSVC 2019 вообще не дает никаких преимуществ, также являются необоснованными утверждениями.

Я также не позволю запугивать себя теми, кто одержим «новейшими и лучшими». И разница на самом деле составляет 68 МБ дополнительного хранилища (я делал локальные статические сборки). msvc2017 просто работает! и не требует дополнительного места.

Плохой камбэк. Никто из сторонников новейшей цепочки инструментов не «запугивает» вас. Придерживаться последней инструментальной цепочки (опять же, в разумных пределах) объективно лучшая политика, особенно когда единственный аргумент против этого заключается в том, что он создает немного большие двоичные файлы (мы не разрабатываем для какой-то встроенной платформы). Кроме того, не рекомендуется выпускать выпуск с набором инструментов, отличным от того CI, который большинство пользователей и участников использовали в течение последних _months_. И в довершение ко всему, вполне вероятно, что есть относительно простое решение для бинарного раздувания — попросите своих друзей с 50 МБ вложить свою энергию в поиск проблемы, а не просто жаловаться на 50 МБ, если это их так сильно беспокоит.

(msvc2017 => msvc2019) можно обсуждать/спорить/спорить и т. д. в другом выпуске _КОГДА_ это становится необходимым

msvc2019 станет для нас гораздо более актуальным, когда мы перейдем на c++17.

Это также станет более актуальным при переходе на Qt 6.0/6.1/6.2, когда Qt потребует msvc2019 & drop (поддержка Windows 7/8/8.1 и 32-разрядных версий) (я знаю, что это еще далеко от реализации)

Хосты и цели разработки в Qt 6.0

Хосты разработки Qt 6.0

Цели разработки Qt 6.0

Хосты разработки Qt 6.1

Цели разработки Qt 6.1

Я не собираюсь дальше спорить о компиляторах. Я не согласен с вами конкретно по qbt. msvc2019 станет для нас гораздо более актуальным, когда мы перейдем на c++17.

ссылка: 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 для выпуска. последние _месяцы_. Если смотреть с этой точки зрения, я считаю, что очень «необходимо» использовать MSVC 2019 для этого выпуска.

Лично у меня много скинов в этой игре: если что-то пойдет не так, я буду иметь дело с большинством отчетов об ошибках типа «ночная/CI-сборка работала нормально, а релизная — нет» и т. д. и т. д. И да, я знаю, что мне «не нужно» иметь с этим дело. Но я не хочу, чтобы проект был завален новыми проблемами после релиза по причине, которой можно избежать. Уже достаточно плохо, что релиз не будет сделан с библиотеками, скомпилированными таким же или подобным образом, как CI.

Меня сбивает с толку, что все это, включая время и усилия, которые я вложил в проект и управление системой отслеживания проблем, не более важно, чем кто-то, одержимый более чем 50 МБ. Кто эти люди, хотя бы? Что они сделали для проекта?

@FranciscoPombal Я не буду здесь обсуждать компилятор. Мое слово окончательное. Релизы будут сделаны с msvc2017.

если я правильно помню, только Qt 5.15 "официально" поддерживает msvc2019. они не запускались там ci на msvc2019 до Qt 5.15
и он все равно не может выпустить с qt 5.15 из-за ошибок, упомянутых ранее.

Послушайте, я хочу покончить с этим так же сильно, как и все остальные, но, по крайней мере, это откровенно безответственно менять набор инструментов в последнюю минуту перед выпуском, когда все остальные, включая вас, использовали и тестировали MSVC 2019 для выпуска. последние месяцы. Если смотреть с этой точки зрения, я считаю, что очень «необходимо» использовать MSVC 2019 для этого выпуска.

Сборки MSVC 2017 проходят боевые испытания с полным циклом выпуска 4.2.x, и в любом случае в msvc 2019 не так много нового, а у msvc 2017 по-прежнему есть основной цикл выпуска, я не могу понять, почему вы так одержимы «последними и лучшими» .

@xavier2k6

Кроме того, предположим, что мы не исправим «проблему» с дополнительными 50 МБ до следующего «большого» релиза. Мы все собираемся вести одно и то же обсуждение? Мы собираемся отложить обновление до Qt 6 из-за этого? Что важнее/не важнее 50 МБ? Мы просто заметаем проблему под ковер, это плохой прецедент.

Подсказка: я могу почти гарантировать, что, судя по мнениям, которые я видел от других с течением времени, обновление до Qt6 будет отложено гораздо дольше, чем это разумно, по всем этим трем причинам и, возможно, больше, в произвольном порядке: Размер установщика 50 МБ, сохранение поддержки Windows 7, сохранение поддержки 32-разрядных сборок.

@jagannatharjun Qt 5.15.1 отлично строится с msvc2017. Единственные связанные проблемы связаны с закрытием контекстного меню при выборе тегов. ИМО, это не блокировщик. Однако Qt 5.15 обеспечивает гораздо лучшую поддержку HiDPI.

@FranciscoPombal Я могу понять, откуда вы пришли, и ваша работа здесь очень ценится!

Замечания, которые вы делаете, имеют отношение к делу, но, к сожалению, я не думаю, что текущие сроки выпуска «нового релиза» позволяют проводить это обсуждение… (в настоящее время)

Я не могу понять, почему вы так одержимы "новейшими и лучшими".

Объективно превосходящая политика не является «навязчивой идеей». Я думаю, вы могли бы сказать, что я одержим тем, чтобы не угождать другим глупым навязчивым идеям. Но сделай мне одолжение и перестань проецировать это на меня, хорошо? Это не усиливает вашу точку зрения.

Вы, ребята, всерьез рассматриваете сохранение разумного темпа обновлений/модернизаций как «навязчивую идею» и не более 50 МБ в установщике. Иисус бля.

@jagannatharjun Qt 5.15.1 отлично строится с msvc2017. Единственные связанные проблемы связаны с закрытием контекстного меню при выборе тегов. ИМО, это не блокировщик. Однако Qt 5.15 обеспечивает гораздо лучшую поддержку HiDPI.

Я согласен, ошибка тегов контекстного меню досадна, но ошибки HiDPI гораздо серьезнее и со временем производят гораздо больше отчетов.

@FranciscoPombal Я могу понять, откуда вы пришли, и ваша работа здесь очень ценится!

Хорошая шутка.

Замечания, которые вы делаете, имеют отношение к делу, но, к сожалению, я не думаю, что текущие сроки выпуска «нового релиза» позволяют проводить это обсуждение… (в настоящее время)

Я вижу, что больше ничего не могу. Ну что ж.

@FranciscoPombal Я могу понять, откуда вы пришли, и ваша работа здесь очень ценится!

Хорошая шутка.

@FranciscoPombal Серьезно?? - Это была не шутка, и я был лично искренен!!!

Замечания, которые вы делаете, имеют отношение к делу, но, к сожалению, я не думаю, что текущие сроки выпуска «нового релиза» позволяют проводить это обсуждение… (в настоящее время)

Я вижу, что больше ничего не могу. Ну что ж.

Не принимайте эту ситуацию на свой счет / близко к сердцу ...... хорошо
........сделай передышку
пусть часть вашей тяжелой работы в проекте хотя бы увидит «основную публику» через новый релиз. (поскольку в настоящее время его могут видеть только такие люди, как я, которые приходят сюда и участвуют/вносят вклад/строят и т. д.

Я только что нажал ветку staging_v4_3_x . Это в основном мастер с обновленным журналом изменений.
Пожалуйста, взгляните на журнал изменений и сообщите мне, если что-то не так или я что-то пропустил.
@glassez

1. Есть ли у # 13234 какие-либо атрибуты, ориентированные на пользователя? Что-то, что должно быть в журнале изменений? например, "улучшить скорость загрузки сессий с сотнями торрентов".
2. Какова цель # 13395. Что оно делает? Должен ли я включить что-то в список изменений?

Чуть позже я рассмотрю проблемы, упомянутые в этой ветке, которые могут привести к тому, что некоторые коммиты не будут включены в выпуск. Я буду держать вас в курсе.

@sledgehammer999

Кроме того, пожалуйста, очистите PPA в процессе. Выпуски Ubuntu, отличные от 18.04 , 20.04 и 20.10 , являются EOL, поэтому архивы для сборок, предназначенных для этих версий, должны быть удалены как можно скорее.

Ubuntu 14.04 и 16.04 не являются EOL. Откуда вы взяли этот список?
https://wiki.ubuntu.com/Релизы

@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 соответствует «атрибутам, с которыми сталкиваются пользователи»:

Это позволяет корректно сохранять данные докачки при некоторых обстоятельствах, например, в состоянии "отсутствующие файлы" (хотя мы и старались запретить это делать ранее, пользователь мог это сделать, например, при изменении какого-либо свойства такого торрента).

Какова цель # 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 была прекращена.

OK.

Кроме того, если кто-то хочет более высокую скорость анонсирования трекера или имеет более медленный выход клиента (по сравнению с 4.2.x) с этой версией, он может попробовать увеличить ограничение «Макс. одновременное HTTP-объявление» в дополнительных настройках.

Это должно быть упомянуто в журнале изменений как пункт?

Черт! Поддерживает ли qBittorrent libtorrent-2.0? Зачем упоминать, как есть? Мы уже говорили об этом.

Затем я перенесу этот элемент в запись о выпуске v4.4.0 (не входит в журнал изменений версии 4.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 меньше, чем наши минимальные требования.

OK. Думаю, теперь все установлено, и я готовлю сборки. Ветка v4_3_x будет отправлена ​​вместе со сборками.

@sledgehammer999 Извините за поздний комментарий, но, пожалуйста, не забудьте упомянуть (в разделе новостей на веб-сайте), что со времени последнего выпуска libtorrent было много исправлений, которые присутствуют в этом, в том числе для известных утечек памяти, проблем со скоростью из-за неправильная логика настроек кэша в Windows и т. д. Вы можете взглянуть на libtorrent 1.2.6-1.2.11 (1.2.11 еще официально не выпущена, но уже имеет несколько записей в журнале изменений) для вдохновения и выбрать наиболее подходящие записи.

Из любопытства, какой коммит libtorrent будет использоваться?

Хорошо, и последний коммит git, как всегда.

@rrrevin

Ubuntu 14.04 и 16.04 не являются EOL. Откуда вы взяли этот список?
https://wiki.ubuntu.com/Релизы

Наверное неправильная формулировка. Для нас это EOL, потому что их версия Qt меньше, чем наши минимальные требования.

Ну, я действительно имел в виду «Конец стандартной поддержки», я думаю, что в любом случае действительно важно. Кроме того, поддержку получают только платные предприятия. Версия 16.04 технически еще даже не достигла «конца стандартной поддержки», но очень близка к этому. И несмотря на это, поддержка OOTB для него была прекращена примерно 2 года назад или около того из-за того, что qBittorrent увеличил минимальную требуемую версию Qt до 5.9.

@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 Я объединил все ваши PR CMake в одну запись. Ваши внутренние запросы на очистку кода не могут быть упомянуты в журнале изменений. Он должен содержать исправления для пользователей. То же самое со многими пиарами @Chocobo1.
Если я пропустил что-то конкретное, пожалуйста, укажите это ниже. Я подожду несколько минут, так как я все еще выполняю административную задачу за кулисами.

@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, считается ли это пользовательским?

ИМО, такая вещь может быть упомянута в новостях (вне журнала изменений).

ИМО, такая вещь может быть упомянута в новостях (вне журнала изменений).

Я мог бы как-то втиснуть ссылку «ночные» на страницу загрузок...

~@glassez~ @ sledgehammer999

ИМО, такая вещь может быть упомянута в новостях (вне журнала изменений).

Я мог бы как-то втиснуть ссылку «ночные» на страницу загрузок...

Просто упомяните материал CI в новостях, я бы не решился связать страницу «ночных» загрузок с более широкой аудиторией, прежде чем у нас будет версия на основе git в исполняемых файлах. В противном случае все пользователи будут сообщать обо всех различных ночных версиях как «4.x.xalpha1», что приведет к путанице.

управление версиями исполняемых файлов на основе git. В противном случае все пользователи будут сообщать обо всех различных ночных версиях как «4.x.xalpha1», что приведет к путанице.

Да, это правильное замечание.

@sledgehammer999

Можете ли вы предложить соответствующую запись журнала изменений (для пользователей, читающих ее)?

«Исправлена ​​неправильная логика анонса во встроенном трекере, в некоторых случаях приводившая к сбоям».

Сборки CI также могут использоваться для вредоносных целей. Путем создания злонамеренного пиара и последующего распространения ссылок.
Я бы рекомендовал не размещать такие ссылки на сайте.

@an0n666

Сборки CI также могут использоваться для вредоносных целей. Путем создания злонамеренного пиара и последующего распространения ссылок.
Я бы рекомендовал не размещать такие ссылки на сайте.

Это тоже хороший момент. Я думаю, мне лучше начать работать над рабочим процессом специально для ночных сборок, которые собираются только из мастера, о котором я говорил ранее. Тогда мы сможем ссылаться на ночные сборки, не опасаясь, что такое произойдет.

Выпуск сделан.
PPA будет очищена завтра.
Подробности о проблеме безопасности через несколько дней.
Организационные изменения планирую через несколько дней.

И, как всегда, спасибо всем за их вклад в этот цикл выпуска.