@sledgehammer999 você deve ler isto => https://github.com/orgs/qbittorrent/teams/bug-handlers/discussions/5

Felizmente não ter o vírus (e espero continuar assim).

Estou feliz por você pessoalmente.

Mas estou muito triste com a situação atual do projeto (e não sou o único que sente o mesmo). A hora da mudança é crítica. Portanto, você deve reestruturar a gestão/manutenção do projeto ou declarar explicitamente que é apenas seu brinquedo pessoal, para que ninguém mais tenha falsas esperanças.

Existem commits que devem ser isentos?

Eu não acho que faz sentido pular quaisquer alterações agora.

De qualquer forma, um novo lançamento está muito atrasado.

Muito.

Devo, como de costume, fazer backport de todos os novos commits master para o branch v4_2_x?

Por que v4.2.x? Há mudanças mais do que suficientes para a v4.3!
Além disso, você pode simplesmente criar uma ramificação v4_3_x em cima do mestre atual, em vez de fazer esse trabalho desnecessário "escolhendo" os commits um por um.

Acabei de ver os commits do release anterior até o master mais recente. (comite títulos e descrições de relações públicas principalmente)

Por que v4.2.x? Há mudanças mais do que suficientes para a v4.3!

Sim. Há uma tonelada de commits. E como o libtorrent 1.1.x foi descartado, ele certamente garante a versão 4.3.x. (E v4.4.x para libtorrent 2.0.xe c++17!!!)
Vou criar um novo PR para o próximo changelog, o mais rápido possível.

Sobre gerenciamento de projetos: Discutiremos isso após o fim de semana / próximo lançamento.

@marreta999

Que bom que você voltou e que está tudo bem.

Devo, como de costume, fazer backport de todos os novos commits master para o branch v4_2_x? Existem commits que devem ser isentos?

Sou indiferente à proposta de rotular a nova versão 4.3.x. Cabe a você e aos outros decidir.

Todos os commits são bons AFAIK. No entanto, muitas correções muito importantes também foram incorporadas ao libtorrent, por isso é importante usar o RC_1_2 mais recente possível para esta nova versão.

Já houve alguns commits sobre o suporte ao BitTorrent V2. No entanto, eu esperaria que este lançamento fosse construído com o último libtorrent RC_1_2 como mencionado acima, então a maioria dos usuários não verá nada disso na prática. Assim, eu colocaria uma nota no changelog explicando isso, para que os usuários não tenham falsas esperanças quando lerem as entradas relacionadas ao BitTorrent V2.

Eu atualizei minha cadeia de ferramentas local. O teste de backport/changelog/minimal levará algum tempo. Mas acho que este fim de semana é um alvo viável, dependendo do tamanho das mudanças.

Você pode, por favor, fornecer detalhes sobre isso? Suponho que você tenha o MSVC 2019 mais recente e _espero_ que esteja usando vcpkg ou similar para as dependências - menos chance de bugs estranhos devido a pequenas discrepâncias na maneira como tudo é construído e mais reprodutibilidade. Você pode conferir o novo GitHub Actions CI para se inspirar. Lembre-se também de usar o CMake para compilar desta vez, ele se tornou o novo sistema de compilação padrão.

Sobre gerenciamento de projetos: Discutiremos isso após o fim de semana / próximo lançamento.

OK, mas mais cedo ou mais tarde, por favor. E devemos continuar a discussão de automatizar ainda mais o processo de lançamento, para que até mesmo o empacotamento possa ser feito automaticamente.

@marreta999

Além disso, limpe o PPA no processo. As versões do Ubuntu diferentes de 18.04 , 20.04 e 20.10 são EOL, portanto, os arquivos para compilações direcionadas a essas versões devem ser removidos o mais rápido possível.

por isso é importante usar o RC_1_2 mais recente possível para esta nova versão.

Isto é desnecessário dizer.
Qt 15.1, openssl 1.1.1h, boost 1.74

RC_2_0 ainda não será usado. Não sem alguns lançamentos beta oficiais.

Suponho que você tenha o MSVC 2019 mais recente e espero que esteja usando vcpkg

Não, ainda estou com msvc2017 para esta versão. A última vez que verifiquei msvc2019 produziu um arquivo .pdb muito grande para qbt. Vou verificar novamente mais tarde, mas não para esta versão.
O resto das dependências são construídas da maneira que sempre fiz as coisas. Mais ou menos descrito aqui: https://github.com/qbittorrent/qBittorrent/wiki/Compiling-with-MSVC-2019- (static-linkage)

Lembre-se também de usar o CMake para compilar desta vez, ele se tornou o novo sistema de compilação padrão .

Aparentemente, eu perdi isso no log do git. Estou meio chateado, mas realmente não posso objetar, pois todos os outros estão se sentindo mais confortáveis ​​​​com o uso do cmake do que do autotools/qmake.
No entanto, por enquanto continuarei usando autotools/qmake para o lançamento. Não tenho tempo para me familiarizar com o cmake para o lançamento.

Vou ver o que fazer com o PPA, embora eles não prejudiquem ninguém.

@sledgehammer999 Eu sei que você não quer usuários normais comentando aqui, então desculpas ...... Eu tenho feito compilações de janelas aqui com o objetivo de resolver problemas / bugs etc.

Eu compilo com MSVC 2019 e executáveis ​​qBittorrent são geralmente em torno de 27 MB e .pdb são 180 MB

Já pensou em usar /pdbstripped ?

Eu compilo com MSVC 2019 e executáveis ​​qBittorrent são geralmente em torno de 27 MB e .pdb são 180 MB

Compare com msvc2017 e mestre atual: exe de 24,4 MB e pdb de 98,1 MB. Como eu disse o pdb é muito grande comparado ao msvc2017.

Também não acho que queremos /pdbstripped. Provavelmente dará backtraces menos úteis quando o programa travar.

Também não acho que queremos /pdbstripped. Provavelmente dará backtraces menos úteis quando o programa travar.

/PDBCompress ?

@marreta999

As compilações de CI automatizadas, que usam CMake + o MSVC 2019 mais recente + vcpkg (https://github.com/qbittorrent/qBittorrent/actions) estão em 57 MiB (executável) + 122 MiB (pdb).

Não, ainda estou com msvc2017 para esta versão. A última vez que verifiquei msvc2019 produziu um arquivo .pdb muito grande para qbt. Vou verificar novamente mais tarde, mas não para esta versão.

Esta não é uma boa razão IMO. O MSVC 2019 contém muitas correções. É (final de) 2020. Ninguém se importa com um tamanho extra de instalação de \~50 MiB (e se o fizerem, que pena lol). Podemos descobrir mais tarde se algo está sobrecarregando o pdb/executável, mas por enquanto tudo funciona e um extra de 50 MiB é uma troca que eu faria em qualquer dia da semana por uma cadeia de ferramentas muito mais recente.

Também não acho que queremos /pdbstripped. Provavelmente dará backtraces menos úteis quando o programa travar.

:+1:, mas isso pode ser devidamente investigado no futuro.

O resto das dependências são construídas da maneira que sempre fiz as coisas. Mais ou menos descrito aqui: https://github.com/qbittorrent/qBittorrent/wiki/Compiling-with-MSVC-2019- (static-linkage)

Aparentemente, eu perdi isso no log do git. Estou meio chateado, mas realmente não posso objetar, pois todos os outros estão se sentindo mais confortáveis ​​​​com o uso do cmake do que do autotools/qmake.
No entanto, por enquanto continuarei usando autotools/qmake para o lançamento. Não tenho tempo para me familiarizar com o cmake para o lançamento.

:-1:, esta não é a forma como a maioria das pessoas testou o qBittorrent nos últimos meses no Windows. Muitas pessoas estavam usando compilações do meu branch CI (CMake + vcpkg) e agora a seção Actions do próprio repositório. Eu diria que é altamente provável que observemos regressões inexplicáveis ​​apenas decorrentes das diferenças no processo de construção se você fizer isso.

@sledgehammer999 Não quero adicionar mais "bloqueadores" antes do lançamento, mas pelo menos esperaria que isso chegasse, já que está basicamente pronto: https://github.com/qbittorrent/qBittorrent/pull/13499

A mudança no padrão para threads de E/S assíncronas será benéfica para muitos usuários.

Não quero desmerecer o msvc2019, mas acho que você está um pouco exagerado ao considerar tudo novo como melhor. Nem sempre é o caso. E sim 50 MB extras para um cliente bt é um grande negócio. É um inchaço desnecessário sem nenhum benefício mensurável (por exemplo, o programa não se torna 1,5x mais rápido).

Por último, sobre os sistemas de compilação: se virmos regressões apenas da alteração do sistema de compilação, há algo seriamente errado com o código. As coisas não deveriam ser tão frágeis.

13499 está fora do escopo, pois trata-se de uma opção libtorrent 2.0.x que ainda não é o padrão. Por fim, o corte será feito no fim de semana.

@marreta999

Não quero desmerecer o msvc2019, mas acho que você está um pouco exagerado ao considerar tudo novo como melhor. Nem sempre é o caso.
E sim 50 MB extras para um cliente bt é um grande negócio. É um inchaço desnecessário sem nenhum benefício mensurável (por exemplo, o programa não se torna 1,5x mais rápido).

Por favor, não descarte meus argumentos como "novo = melhor". E acho que você está um pouco "exagerado" ao aderir a uma cadeia de ferramentas pior para 50 MiB. É claro que você nunca (ou muito raramente) vê uma aceleração de "1,5x" ao atualizar sua cadeia de ferramentas. Mas essa é uma barra irreal para definir. Com uma cadeia de ferramentas mais recente, pode não haver uma aceleração de "1,5x", mas sempre há pequenas melhorias de desempenho, melhor suporte a idiomas, melhor geração de código (às vezes levando a menos bugs), ... melhorias no MSVC 2019.

Mais uma vez, concordo que devemos cortar esses 50 MiB extras se possível, mas meu ponto é que, se não pudermos fazer isso a tempo para o próximo lançamento (ou nunca!), _tudo bem_. Além disso, não há implicação de que isso continue acontecendo a cada lançamento novamente (eu também ficaria irritado nesse caso). Esta é claramente uma questão pontual. Como usuário, eu não gostaria de ouvir "aqui está seu binário de pior qualidade, mas pelo menos economizamos 50 MiB, mano". 50 MiB é um erro de arredondamento hoje em dia (para programas de desktop, pelo menos; é claro que no mundo incorporado e tal não é o caso). Sinto muito, mas você está errado se pensa o contrário.

Por último, sobre os sistemas de compilação: se virmos regressões apenas da alteração do sistema de compilação, há algo seriamente errado com o código. As coisas não deveriam ser tão frágeis.

Não necessariamente. Algo pode estar seriamente errado com o próprio sistema de compilação. Veja o estado anterior do buildsystem CMake, antes da minha revisão PR. Antes disso, compilar com o CMake causava alguns bugs. Alguns problemas (às vezes sérios!) realmente decorrem de sistemas de compilação incorretos/ruins e receitas de compilação. Não importa quão robusto seja o seu código, se você o construir errado, ele irá quebrar, às vezes de maneiras muito espetaculares, mas difíceis de diagnosticar.

13499 está fora do escopo, pois trata-se de uma opção libtorrent 2.0.x que ainda não é o padrão. Por fim, o corte será feito no fim de semana.

Por favor, veja o resto da discussão. Esse PR também altera o número padrão de encadeamentos de E/S assíncronos, de modo que, por padrão, pelo menos 2 encadeamentos de hash são usados ​​ao compilar contra libtorrent 1.2.x também. Isso resulta em um aumento de desempenho muito significativo para usuários de SSD (mais de 1,5x, na verdade, heh) enquanto fornece um ganho muito marginal para usuários de HDD também.

@marreta999

Aqui está alguma ajuda para você começar:

• o novo tutorial para construir com CMake estaticamente no Windows: https://github.com/qbittorrent/qBittorrent/wiki/Compilation :-Windows-(MSVC-2019,-64-bit,-static-linkage)
• lista de opções + breve tutorial/intro do CMake: https://github.com/qbittorrent/qBittorrent/wiki/Compilation-with-CMake :-common-information

Caso você não esteja usando vcpkg, ou se você estiver usando vcpkg para alguns pacotes, mas não para outros, você só precisa passar adicionalmente as dicas apropriadas que informam ao CMake onde encontrar os arquivos de configuração para os pacotes, como -DLibtorrentRasterbar_DIR=C:\path\to\libtorrent-install-dir\lib\cmake\LibtorrentRasterbar . Em caso de dúvida, você pode simplesmente executar o configure até que seja bem-sucedido, corrigindo cada mensagem de erro sobre cada pacote, uma de cada vez, à medida que aparecem, pois as mensagens de erro são úteis o suficiente para que você sempre possa entender e descobrir o que precisa adicionar Próximo.

Não vou discutir mais sobre compiladores. Eu não concordo com você especificamente para qbt. msvc2019 se tornará muito mais relevante para nós quando mudarmos para c++17. Por fim, para um usuário de cliente bt, tudo o que ele se importa é se o cliente pode atingir a velocidade de cima para baixo/para cima. Essa é a métrica para binário de qualidade "melhor" ou "pior". msvc2017 consegue isso sem inchaço extra. --Eu mantenho meu julgamento até refazer minhas compilações com msvc2019--

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

Faz diferença como um pacote é compilado/instalado? Atualmente eu não tenho cmake pasta em lib para qualquer boost, libtorrent, openssl. Apenas para qt.
PS: boost e libtorrent são compilados usando b2. Openssl usando seu script de configuração.

@marreta999

O único requisito é que você construa libtorrent com CMake, IIRC. Todos os outros pacotes geram os arquivos de configuração necessários por padrão ou são suportados pelo CMake de alguma forma:

• libtorrent deve ser compilado com o CMake para que os arquivos apropriados sejam gerados. Isso é abordado especificamente no tutorial Wiki.
• O CMake oferece suporte nativo ao OpenSSL por meio de um módulo de localização empacotado: https://cmake.org/cmake/help/latest/module/FindOpenSSL.html#hints. Você só precisa definir OPENSSL_ROOT_DIR . Exemplo: -DOPENSSL_ROOT_DIR=C:\Qt\Tools\OpenSSL\Win_x64
• boost gera os arquivos necessários por padrão. Você só precisa definir Boost_DIR Exemplo: -DBoost_DIR=C:\path\to\boost_1_73_0\stage\lib\cmake\Boost-1.73.0
• Para zlib você tem que passar alguns caminhos. Exemplo: -DZLIB_INCLUDE_DIR=C:\path\to\zlib-1.2.11\build -DZLIB_LIBRARY=C:\path\to\zlib-1.2.11\build\libzlibstatic.a
• Qt gera os arquivos necessários, suponho que você já tenha descoberto o sinalizador de tempo de configuração necessário para apontar para eles.

Novamente, se estiver faltando algum deles, o CMake informará sobre isso na etapa de configuração e sugerirá exatamente o que deseja que você adicione.

Concordo com marreta999.
Binário menor é sempre melhor. Especialmente devido ao histórico de lançamentos anteriores.
Muitos ainda têm uma internet lenta. Também o site que serve os binários pode ser lento para alguns usuários com base na localização.
Nesses casos, um pequeno binário permite um download mais rápido. As pessoas podem ficar desencorajadas a atualizar se suspeitarem de bloatware desnecessário.

tornou-se o novo sistema de compilação padrão.

buildsystem padrão de quê?

tornou-se o novo sistema de compilação padrão.

buildsystem padrão de quê?

ele até declarou qmake/autotools obsoleto https://github.com/qbittorrent/qBittorrent/wiki

ele até declarou qmake/autotools obsoleto https://github.com/qbittorrent/qBittorrent/wiki

Essa arbitrariedade está começando a realmente enfurecer!

tornou-se o novo sistema de compilação padrão.
buildsystem padrão de quê?

Essa arbitrariedade está começando a realmente enfurecer!

oh uau! Portanto, não é uma decisão real! Eu não me sinto chateado depois de tudo.

@FranciscoPombal
Por favor, não distraia @sledgehammer999 com conversas inúteis sobre diferentes ferramentas de compilação, sistemas de compilação, etc. Deixe que o próximo lançamento seja feito da maneira usual - será mais rápido e confiável. Precisamos ter tempo para resolver questões organizacionais para que possamos manter o projeto à tona, independentemente do fato de um de seus membros desaparecer por muito tempo.
Também não faz sentido discutir o libtorrent-2.0 no contexto do próximo lançamento (e de todo o próximo branch), já que não temos suporte para ele e nem podemos prever quando ele será totalmente implementado.

É (final de) 2020. Ninguém se importa com um tamanho extra de instalação de ~ 50 MiB (e se o fizerem, muito ruim lol).

Meus dois computadores principais têm 9 e 12 anos (embora eu os tenha melhorado recentemente instalando SSD como discos do sistema). Muitos usam hardware ainda mais antigo. Não é porque gostamos. Simplesmente não temos capacidade financeira/outra para atualizá-lo a cada 2-3 anos. Se você não é capaz de nos entender, isso ainda não lhe dá o direito de tirar sarro de nós.

PS No entanto, mesmo 10 anos atrás eu não teria me preocupado tanto com esses 50 megabytes.

@an0n666 @sledgehammer999 @glassez

Concordo com marreta999.
Binário menor é sempre melhor. Especialmente devido ao histórico de lançamentos anteriores.
Muitos ainda têm uma internet lenta. Também o site que serve os binários pode ser lento para alguns usuários com base na localização.
Nesses casos, um pequeno binário permite um download mais rápido. As pessoas podem ficar desencorajadas a atualizar se suspeitarem de bloatware desnecessário.

Vamos lá agora, o download do aplicativo é um custo único. Mesmo a 10 Mb/s, 50 MiB extras são apenas 50 segundos extras. Se essas pessoas estão tão incomodadas com isso, é melhor elas virem aqui e ajudarem a resolver o problema elas mesmas. Não se deixe levar por pessoas obsessivas compulsivas que reclamam de 50 MiB. Eles querem voltar para o uT 2.2.1 por causa disso? Multar. Mesmo na Somália, você pode obter 10 Mb/s em média: https://www.speedtest.net/global-index , e duvido que um cliente BitTorrent seja a principal preocupação da maioria dos somalis nativos. As compilações são fornecidas tanto pelo Fosshub quanto pelo Sourceforge, que provavelmente nunca se tornarão o gargalo, a menos que Kim Kardashian diga a todos os seus fãs para baixar o qBittorrent ou algo assim.

Também,

Binário menor é sempre melhor. Especialmente devido ao histórico de lançamentos anteriores.

Citação necessária. Onde está a correlação entre "melhor histórico" e "tamanho binário menor"? Melhor histórico de quê? Atuação? Confiabilidade?

buildsystem padrão de quê?

ele até declarou qmake/autotools obsoleto https://github.com/qbittorrent/qBittorrent/wiki

Essa arbitrariedade está começando a realmente enfurecer!

oh uau! Portanto, não é uma decisão real! Eu não me sinto chateado depois de tudo.

Nós concordamos que o sistema de compilação CMake era o futuro. É um erro manter dois sistemas de compilação, como já disse muitas vezes antes. Isso é mencionado em contribuições recentes: https://github.com/qbittorrent/qBittorrent/pull/13509#issuecomment -708072078

Falando em bloatware: Veja o esforço duplicado que temos devido à manutenção de 2 sistemas de compilação. Veja os vários arquivos de autotools bloat que temos no repositório.

Por favor, não distraia @sledgehammer999 com conversas inúteis sobre diferentes ferramentas de compilação, sistemas de compilação, etc. Deixe que o próximo lançamento seja feito da maneira usual - será mais rápido e confiável.

Mais um ataque provavelmente ao membro mais ativo deste repositório nos últimos meses, e que fez contribuições cruciais, especialmente no campo de sistemas de compilação, ferramentas, etc. As novas compilações e modificações no sistema de compilação _são_ mais confiáveis. Pelo que me lembro, houve até casos de problemas que desapareceram simplesmente construindo com o novo método. Graças aos meus esforços, agora podemos obter compilações mais confiáveis ​​muito mais rapidamente nas mãos dos usuários. Certamente NÃO é inútil. Tenho planos de melhorar ainda mais isso, até o lançamento oficial, mas não conte comigo se continuar depreciando minha participação assim.

Eu não estou distraindo ele, estou colocando-o em dia com os desenvolvimentos importantes dos últimos meses. O ônus é dele para alcançá-lo.
Agora que o trenó voltou, eu quero fazer a construção sair pela porta tanto quanto qualquer um, mas eu quero fazê-lo _certo_. sledge estar de volta não deve significar que temos que voltar aos nossos velhos hábitos (mesmo para esta versão parece um compromisso), deve significar que podemos evoluir _mais rápido_ para chegar ao lugar em que queremos estar.

Precisamos ter tempo para resolver questões organizacionais para que possamos manter o projeto à tona, independentemente do fato de um de seus membros desaparecer por muito tempo.

Parte do problema é depender de uma única pessoa para produzir manualmente compilações com um sistema de compilação antigo e menos sustentável, pulando em aros apenas por causa de 50 MiB (que pode ser resolvido mais tarde) etc. Considere o fato de que estamos nos desviando do toolchain que usamos em nosso CI apenas para isso. Mesmo que não seja realmente um grande problema agora, é um mau princípio e precedente.

Também não faz sentido discutir o libtorrent-2.0 no contexto do próximo lançamento (e de todo o próximo branch), já que não temos suporte para ele e nem podemos prever quando ele será totalmente implementado.

Não precisamos falar sobre o libtorrent 2.0. Apenas uma pequena nota explicando que o suporte para V2 ainda não está presente, apesar de algumas menções ao suporte V2 aparecerem nas mensagens de confirmação no changelog. Por exemplo, 19d77b0881dc777b7930106869854067e5b2faba. (a menos é claro que você não escolha esses commits para a versão 4.3.0, mas isso complica as coisas IMO).

Meus dois computadores principais têm 9 e 12 anos (embora eu os tenha melhorado recentemente instalando SSD como discos do sistema). Muitos usam hardware ainda mais antigo. Não é porque gostamos. Simplesmente não temos capacidade financeira/outra para atualizá-lo a cada 2-3 anos. Se você não é capaz de nos entender, isso ainda não lhe dá o direito de tirar sarro de nós.

PS No entanto, mesmo 10 anos atrás eu não teria me preocupado tanto com esses 50 megabytes.

Por favor, aponte para onde eu "zombei" de usuários de baixa especificação. Eu também tenho um laptop C2D de 12 anos no qual instalei um SSD (a conexão é apenas SATA II!) que ainda uso com frequência. Também não possuo nenhuma máquina com processador fabricado nos últimos 3 anos e gostaria de poder obter um AMD Ryzen no futuro. Eu certamente não "atualizo a cada 2-3 anos". Eu entendo e concordo com você. Eu apenas tirei sarro de pessoas que reclamam de 50 MiB em um desktop/laptop hoje em dia (leia-se: últimos 15+ anos), porque essas pessoas merecem ser ridicularizadas.

Mais um ataque provavelmente ao membro mais ativo deste repositório nos últimos meses

Por favor, pare de procurar algum subtexto oculto em meus comentários. Acabei de dizer o que disse. Espero que sua reação não confunda ninguém.

Eu não estou distraindo ele, estou colocando-o em dia com os desenvolvimentos importantes dos últimos meses. O ônus é dele para alcançá-lo.

Tudo tem seu tempo e lugar.
Por que pressionar @sledgehammer999 aqui e agora, se isso só pode levar ao fato de que ele não terá tempo nem para fazer o próximo lançamento, nem para reestruturar a gestão/manutenção do projeto antes que ele desapareça novamente, para que não sejamos capaz de continuar o trabalho de pleno direito na sua ausência.

Não precisamos falar sobre o libtorrent 2.0. Apenas uma pequena nota explicando que o suporte para V2 ainda não está presente, apesar de algumas menções ao suporte V2 aparecerem nas mensagens de confirmação no changelog.

Eu mencionei repetidamente que o log de alterações não deve copiar cegamente o histórico do git. Você deve ter em mente que:

1. alguns commits fazem parte de uma única correção/melhoria/recurso, então faz sentido mencioná-lo em sua totalidade;
2. alguns commits corrigem erros intermediários que não estavam presentes na versão anterior, então não faz sentido mencioná-los;
3. alguns commits são parte de algum trabalho inacabado, então não faz sentido mencioná-los.

@marreta999
Por favor, seja notificado para o problema #13519.

EDIT: alarme falso: https://github.com/qbittorrent/qBittorrent/issues/13519#issuecomment -710744534
EDIT(FranciscoPombal) não é um alarme falso: https://github.com/qbittorrent/qBittorrent/issues/13519#issuecomment -710911209

@sledgehammer999 @Chocobo1 @glassez

Desculpe pelo ping em massa, mas este também parece bastante crítico e, infelizmente, um pouco confuso agora (também estou confuso neste momento sobre qual é o problema): https://github.com/ qbittorrent/qBittorrent/issues/13389. Talvez um de vocês possa lançar alguma nova luz sobre isso?

Uma coisa é certa; Eu não gostaria de arriscar quebrar as configurações *arr de todos com a primeira versão 4.3.x.

este também parece bastante crítico e, infelizmente, um pouco confuso agora (também estou confuso neste ponto sobre qual é o problema): #13389. Talvez um de vocês possa lançar alguma nova luz sobre isso?

Uma coisa é certa; Eu não gostaria de arriscar quebrar as configurações *arr de todos com a primeira versão 4.3.x.

Por favor, não comece a surtar no final. Qual é o problema? (Além de problemas com a compreensão da lógica do aplicativo.) Não alteramos o código relacionado, alteramos? Com certeza não li o tópico inteiro. Se houver evidências claras de um bug no aplicativo, por favor me indique um comentário específico.

@glassez

Por favor, não comece a surtar no final. Qual é o problema? (Além de problemas com a compreensão da lógica do aplicativo.) Não alteramos o código relacionado, alteramos? Com certeza não li o tópico inteiro. Se houver evidências claras de um bug no aplicativo, por favor me indique um comentário específico.

Ninguém está surtando, só precisamos estar cientes das possíveis consequências. A questão é que outra pessoa leia o tópico com cuidado e com a cabeça clara. Quando tentei lidar com isso, não tinha certeza se era uma regressão legítima ou uma deturpação do usuário de uma mudança recente, ou se a recente mudança de redação expôs um defeito inesperado ou o quê. Isso é agravado pelo fato de que eu nunca usei nenhum software *arr , mas sei que muitas pessoas usam. Independentemente disso, aqui estão os relatórios originais nos repositórios *arr : https://github.com/Radarr/Radarr/issues/5032 https://github.com/Sonarr/Sonarr/issues/3968 , se você quer dar uma olhada.

Ola pessoal,

Acabei de notar que alguém mencionou FOSSHUB em um comentário anterior. Eu li o tópico e quero dizer isso. Supondo que o qBittorrent tenha cerca de 50 MB, isso não faz diferença para nós. O mesmo com qualquer pico de tráfego, alguém mencionou Kim Kardashian. Por favor, faça com que ela recomende o qBittorrent; Tenho certeza que não vamos cair. Podemos absorver esse tráfego. Por exemplo, sempre que um novo qBittorrent é lançado, temos visto milhares de solicitações de atualização por segundo.

O que estou tentando dizer é que você não deve se preocupar com isso.

Obrigado!

meus 1,5 centavos, ele compila e funciona melhor no msvc2019 por qualquer motivo
50mb de espaço em disco não é absolutamente nada em 2020, se o seu sistema é tão restrito, então você está executando um cliente mais leve ou qbt-cli de qualquer maneira

nunca adie colocar o seu projecto no melhor e mais recente quando pode ser feito sem causar erros quanto mais esperar mais corre o risco de ficar para trás e ficar preso num compilador morto sem suporte nunca é divertido para ninguém

Acho que o sledge estava se referindo a problemas como esses sendo abertos mesmo após apenas 12 MiB de aumento no tamanho do instalador.
https://github.com/qbittorrent/qBittorrent/issues/12247

Portanto, não são nem 50 MiB, mas apenas 12 MiB que as pessoas estão chegando ao ponto de criar um ticket de problema.

@sledgehammer999 "IF" você vai usar o Qt 5.15.0/5.15.1 na próxima versão, tome nota de (menu de contexto fecha depois de escolher uma tag) #13492

Simplificando, acho que se for rotulado como 4.3, ninguém vai reclamar sobre o instalador ser maior, seria esperado com certeza! Manter cadeias de ferramentas antiquadas honestamente parece uma representação adequada do processo de lançamento do qBittorrent.

Animado para finalmente ver isso acontecer, eu quase perdi a esperança de ver algo este ano.

Acho que o sledge estava se referindo a problemas como esses sendo abertos mesmo após apenas 12 MiB de aumento no tamanho do instalador.

12247

>

Portanto, não são nem 50 MiB, mas apenas 12 MiB que as pessoas estão chegando ao ponto de criar um ticket de problema.

Assim? A única resposta apropriada para esses bilhetes é "tanto faz, cara.". Eu não entendo a obsessão em se curvar para essas pessoas. Como eu disse em https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -708436739, é claro que sempre faremos o nosso melhor para evitar tais aumentos de tamanho, mas não devemos sacrificar mais nada apenas por 50 MiB, e se algumas pessoas estão incomodadas com isso, elas podem vir aqui e consertar elas mesmas.

não devemos sacrificar mais nada

Sinto muito, mas realmente não vejo o que sacrificamos por não ir para o compilador mais recente e maior (dúvida). Não há nada tangível de ir para o compilador mais recente. Não é como se o msvc2017 fosse um compilador antigo.

@marreta999

Sinto muito, mas realmente não vejo o que sacrificamos por não ir para o compilador mais recente e maior (dúvida). Não há nada tangível de ir para o compilador mais recente. Não é como se o msvc2017 fosse um compilador antigo.

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

meus 1,5 centavos, ele compila e funciona melhor no msvc2019 por qualquer motivo

Como mencionado anteriormente, lembro de outros relatos sobre isso no rastreador de problemas ou em outros canais de comunicação. Eu não estou inventando isso.

Independentemente disso, deve-se sempre tentar usar a cadeia de ferramentas mais recente (dentro do razoável, mas o MSVC 2019 está maduro neste momento), a menos que haja uma razão muito boa para não fazê-lo. Além disso, as compilações do MSVC 2019 foram amplamente testadas em batalha nos últimos meses, fornecidas por mim, xavier2k6 ou outros, ou agora, mais recentemente, com o fluxo de trabalho oficial do GitHub Actions. 50 MiB não é um bom motivo, como muitas pessoas estão tentando lhe dizer. Não se deixe intimidar por aqueles que são obcecados por mais de 50 MiB!! Eu cuidarei pessoalmente desses relatórios, você nem precisará vê-los.

A atualização para o MSVC2019 é algo que leva muito tempo para ser feito? É apenas um caso de quando não, se não é? Portanto, se não for este lançamento, certamente o próximo, dado que os lançamentos geralmente têm quase meses de intervalo.

https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -711123971 é apenas um relatório subjetivo que provavelmente é afetado pelo uso das últimas bibliotecas e código qbt. Não por causa do compilador.

A atualização para o MSVC2019 é algo que leva muito tempo para ser feito? É apenas um caso de quando não, se não é? Portanto, se não for este lançamento, certamente o próximo, dado que os lançamentos geralmente têm quase meses de intervalo.

o motivo é dado aqui https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -708055242

Não se deixe intimidar por aqueles que são obcecados por mais de 50 MiB!!

Também não me deixarei intimidar por aqueles que são obcecados pelo "mais recente e melhor". E a diferença é, na verdade, 68 MB de armazenamento extra (eu fiz compilações estáticas locais). msvc2017 simplesmente funciona! e não requer espaço extra.

13505 (comentário) é apenas um relatório subjetivo que provavelmente é afetado pelo uso das últimas libs e código qbt. Não por causa do compilador.

E seus comentários sobre o MSVC 2019 não fornecer nenhum benefício também são afirmações infundadas.

Também não me deixarei intimidar por aqueles que são obcecados pelo "mais recente e melhor". E a diferença é, na verdade, 68 MB de armazenamento extra (eu fiz compilações estáticas locais). msvc2017 simplesmente funciona! e não requer espaço extra.

Mau retorno. Ninguém defendendo a mais recente cadeia de ferramentas está "intimidando" você. Aderir à cadeia de ferramentas mais recente (novamente, dentro da razão) é objetivamente a melhor política, especialmente quando o único argumento contra ela é que ela produz binários um pouco maiores (não estamos desenvolvendo para alguma plataforma incorporada). Além disso, não é uma boa política fazer um lançamento com uma cadeia de ferramentas diferente daquela que a maioria dos usuários e contribuidores tem usado nos últimos _meses_. E para completar, é provável que haja uma solução relativamente simples para o inchaço binário - peça aos seus amigos de 50 MiB para investir sua energia em encontrar o problema, em vez de apenas reclamar sobre 50 MiB se os incomodar tanto.

(msvc2017 =>msvc2019) pode ser discutido/argumentado/debatido etc em outra questão _QUANDO_ se torna necessário

msvc2019 se tornará muito mais relevante para nós quando mudarmos para c++17.

Também se tornará mais relevante na mudança para o Qt 6.0/6.1/6.2 quando o Qt exigir msvc2019 & drop (suporte ao Windows 7/8/8.1 e 32 bits) (que está muito longe de ser implementado, eu sei)

Hosts e destinos de desenvolvimento no Qt 6.0

Hosts de desenvolvimento Qt 6.0

Metas de desenvolvimento do Qt 6.0

Hosts de desenvolvimento Qt 6.1

Metas de desenvolvimento do Qt 6.1

Não vou discutir mais sobre compiladores. Eu não concordo com você especificamente para qbt. msvc2019 se tornará muito mais relevante para nós quando mudarmos para c++17.

referência: https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -708094578

POR AGORA!, PODEMOS TODOS DE UMA VEZ POR TODAS ESTACIONAR ISSO AQUI PARA OUTRA VEZ?

Vamos lançar 4.2.x/4.3.x pela porta!

(msvc2017 =>msvc2019) pode ser discutido/argumentado/debatido etc em outra questão QUANDO for necessário

POR AGORA!, PODEMOS TODOS DE UMA VEZ POR TODAS ESTACIONAR ISSO AQUI PARA OUTRA VEZ?

Vamos lançar 4.2.x/4.3.x pela porta!

Olha, eu quero isso com tanto quanto qualquer outra pessoa, mas se nada mais, é francamente irresponsável alterar a cadeia de ferramentas no último minuto para o lançamento quando todos os outros, incluindo você, estão usando e testando com o MSVC 2019 para o últimos meses_. Quando visto desta lente, acredito que seja muito "necessário" usar o MSVC 2019 para esta versão.

Pessoalmente, tenho muita pele neste jogo: se algo der errado, serei eu lidando com a maioria dos relatórios de bugs do tipo "a compilação noturna/CI funcionou bem, mas o lançamento não" etc etc. E sim, eu sei que não "tenho" que lidar com isso. Mas eu não quero o projeto inundado com novos problemas após um lançamento por um motivo que pode ser evitado. Já é ruim o suficiente que o lançamento não seja feito com bibliotecas compiladas da mesma maneira ou de maneira semelhante ao CI.

Fico perplexo como tudo isso, incluindo o tempo e o esforço que coloquei no projeto e o gerenciamento do rastreador de problemas, não é mais importante do que alguém obcecado por mais de 50 MiB. Quem são essas pessoas, mesmo? O que eles fizeram pelo projeto?

@FranciscoPombal Não terei mais nenhuma discussão sobre o compilador aqui. Minha palavra é definitiva. Os lançamentos serão feitos com msvc2017.

se bem me lembro, apenas Qt 5.15 "oficialmente" suporta msvc2019. eles não começaram a rodar lá ci no msvc2019 até o Qt 5.15
e ele não pode liberar com qt 5.15 de qualquer maneira por causa de bugs mencionados anteriormente.

Olha, eu quero isso com tanto quanto qualquer outra pessoa, mas se nada mais, é francamente irresponsável alterar a cadeia de ferramentas no último minuto para o lançamento quando todos os outros, incluindo você, estão usando e testando com o MSVC 2019 para o últimos meses. Quando visto desta lente, acredito que seja muito "necessário" usar o MSVC 2019 para esta versão.

As compilações do MSVC 2017 são testadas em batalha com todo o ciclo de lançamento 4.2.x e não há muito de novo no msvc 2019 de qualquer maneira e o msvc 2017 ainda tem o ciclo de lançamento mainstream, não consigo entender por que você está tão obcecado com "o mais recente e o melhor" .

@xavier2k6

Além disso, suponha que não corrigimos o "problema" extra de 50 MiB antes do próximo "grande" lançamento. Vamos todos ter essa mesma discussão então? Vamos adiar a atualização para o Qt 6 por causa disso? O que é/não é mais importante que 50 MiB? Estamos apenas varrendo o problema para debaixo do tapete, é um mau precedente.

Dica, posso quase garantir que, pelas opiniões que tenho visto de outras pessoas ao longo do tempo, a atualização para o Qt6 será adiada por muito mais tempo do que o razoável, por todos esses 3 motivos, e possivelmente mais, em nenhuma ordem específica: extra Tamanho do instalador de 50 MiBs, mantendo o suporte ao Windows 7 ativo, mantendo o suporte para compilações de 32 bits ativo.

@jagannatharjun Qt 5.15.1 compila bem com msvc2017. Os únicos problemas vinculados são sobre o fechamento do menu de contexto ao selecionar tags. IMO, isso não é um bloqueador. O Qt 5.15 traz um suporte HiDPI muito melhor.

@FranciscoPombal Eu posso entender de onde você está vindo e seu trabalho aqui é muito apreciado!

Os pontos que você faz têm relevância, mas, infelizmente, não acho que o prazo atual para lançar o "novo lançamento" permita essa discussão .... (no momento)

Não consigo entender por que você está tão obcecado com "o mais recente e o melhor".

Políticas objetivamente superiores não são "obsessões". Acho que você poderia dizer que estou obcecado em não atender a outras obsessões estúpidas. Mas faça-me um favor e pare de projetar isso em mim, sim? Não fortalece seu ponto.

Vocês estão pensando seriamente em manter um ritmo razoável de atualizações/modernização como uma "obsessão" e não ser mais importante que 50 MiB no instalador. Jesus foda-se.

@jagannatharjun Qt 5.15.1 compila bem com msvc2017. Os únicos problemas vinculados são sobre o fechamento do menu de contexto ao selecionar tags. IMO, isso não é um bloqueador. O Qt 5.15 traz um suporte HiDPI muito melhor.

Concordo, o bug das tags de menu de contexto é lamentável, mas os bugs do HiDPI são muito mais sérios e produzem muito mais relatórios ao longo do tempo.

@FranciscoPombal Eu posso entender de onde você está vindo e seu trabalho aqui é muito apreciado!

Boa piada.

Os pontos que você faz têm relevância, mas, infelizmente, não acho que o prazo atual para lançar o "novo lançamento" permita essa discussão .... (no momento)

Vejo que não posso fazer mais nada. Ah bem.

@FranciscoPombal Eu posso entender de onde você está vindo e seu trabalho aqui é muito apreciado!

Boa piada.

@FranciscoPombal Sério?? - Isso não foi uma piada e eu estava/estou sendo pessoalmente sincero!!!

Os pontos que você faz têm relevância, mas, infelizmente, não acho que o prazo atual para lançar o "novo lançamento" permita essa discussão .... (no momento)

Vejo que não posso fazer mais nada. Ah bem.

Não leve essa situação para o lado pessoal/a sério...... ok
........ respire fundo
deixe parte do seu trabalho duro no projeto, pelo menos, conseguir ver o "mainstrem public" através do novo lançamento. (como atualmente só pode ser visto por pessoas como eu que vêm aqui e participam/contribuem/construem etc

Acabei de empurrar um ramo staging_v4_3_x . É basicamente mestre com um changelog atualizado.
Por favor, dê uma olhada no Changelog e me diga se algo está errado ou eu perdi alguma coisa.
@glassez

1. O #13234 tem algum atributo voltado para o usuário? Algo que deveria estar no changelog? por exemplo, "melhorar a velocidade de carregamento de sessões com centenas de torrents".
2. Qual é o propósito de #13395. O que isso faz? Devo incluir algo no changelog?

Daqui a pouco, examinarei os problemas mencionados neste tópico que podem fazer com que alguns commits não sejam incluídos para lançamento. Manterei você informado.

@marreta999

Além disso, limpe o PPA no processo. As versões do Ubuntu diferentes de 18.04 , 20.04 e 20.10 são EOL, portanto, os arquivos para compilações direcionadas a essas versões devem ser removidos o mais rápido possível.

Ubuntu 14.04 e 16.04 não são EOL. De onde você tirou essa lista?
https://wiki.ubuntu.com/Releases

@sledgehammer999 Parece que você perdeu https://github.com/qbittorrent/qBittorrent/pull/13188 para changelog

também, você pode adicionar uma nota no changelog que
"Os pacotes de temas anteriores não funcionarão corretamente com esta versão devido a alterações no formato dos arquivos do pacote, entre em contato com o provedor do tema para obter uma correção. Pode-se ler mais sobre o novo formato aqui https://github.com/qbittorrent/ qBittorrent/wiki/How-to-use-custom-UI-themes " ou algo parecido.
Na verdade, isso é por causa de https://github.com/qbittorrent/qBittorrent/pull/12755/files

Eu acho que deve ser mencionado que o suporte para RC1_1 libtorrent foi descartado.

Além disso, se alguém quiser uma taxa de anúncio de rastreador mais rápida ou estiver tendo uma saída de cliente mais lenta (em comparação com 4.2.x) com esta versão, eles podem tentar aumentar o limite de "Anúncio HTTP simultâneo máximo" das configurações avançadas.

O #13234 tem algum atributo voltado para o usuário? Algo que deveria estar no changelog? por exemplo, "melhorar a velocidade de carregamento de sessões com centenas de torrents".

Desculpe, não me lembro de tudo... foi principalmente melhoria interna. Talvez a próxima parte da descrição do PR se encaixe em "atributos voltados para o usuário":

Ele permite salvar corretamente os dados de currículo em algumas circunstâncias, por exemplo, no estado "arquivos ausentes" (embora tenhamos tentado impedir que isso fosse feito anteriormente, o usuário poderia fazê-lo ao, por exemplo, alterar alguma propriedade de tal torrent).

Qual é o propósito de #13395. O que isso faz? Devo incluir algo no changelog?

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

Eu acho que deve ser mencionado que o suporte para RC1_1 libtorrent foi descartado

👍

RECURSO: Adicione suporte para criar torrents v2 (requer libtorrent 2.0.x) (Chocobo1)

Droga! O qBittorrent já suporta libtorrent-2.0? Por que mencioná-lo como é? Já falamos sobre isso.

também, você pode adicionar uma nota no changelog que
"Os pacotes de temas anteriores não funcionarão corretamente com esta versão devido a alterações no formato dos arquivos do pacote, entre em contato com o provedor do tema para obter uma correção. Pode-se ler mais sobre o novo formato aqui https://github.com/qbittorrent/ qBittorrent/wiki/How-to-use-custom-UI-themes " ou algo parecido.
Na verdade, isso é por causa de https://github.com/qbittorrent/qBittorrent/pull/12755/files

Acho que vou adicionar isso à seção "notícias" do site. Fora das mudanças, no texto introdutório.

Eu acho que deve ser mencionado que o suporte para RC1_1 libtorrent foi descartado.

OK.

Além disso, se alguém quiser uma taxa de anúncio de rastreador mais rápida ou estiver tendo uma saída de cliente mais lenta (em comparação com 4.2.x) com esta versão, eles podem tentar aumentar o limite de "Anúncio HTTP simultâneo máximo" das configurações avançadas.

Isso deve ser mencionado no changelog como um item?

Droga! O qBittorrent já suporta libtorrent-2.0? Por que mencioná-lo como é? Já falamos sobre isso.

Então, vou mover este item para a entrada de versão v4.4.0 (não faz parte do log de alterações da v4.3.0). A menos que o suporte oficial ao libtorrent-2.0 seja introduzido anteriormente. Isso é satisfatório?

Aqui está o changelog atualizado: https://github.com/qbittorrent/qBittorrent/commit/0302e8abbc545d13b7be51e011d2795a9bb3ea73

Isso deve ser mencionado no changelog como um item?

Acho melhor se postado como notícia. Como os usuários com milhares de torrents/muitos rastreadores por torrent podem notar o comportamento de anúncio lento.

Atualizado novamente: https://github.com/qbittorrent/qBittorrent/commit/727dec97540091f891991113299fa38468e13885

Anúncio: Um atraso muito pequeno deve ser esperado. Eu tenho que fazer uma recompilação parcial da cadeia de ferramentas por causa de um problema de segurança que fui informado por e-mail. Os detalhes serão disponibilizados alguns dias após o lançamento. IMO, a gravidade é provavelmente menor porque a exploração requer que alguém mal-intencionado tenha acesso local ou já esteja executando um aplicativo mal-intencionado em seu sistema. Nos dois casos você já está ferrado mesmo sem o problema de segurança do qbt.

Ubuntu 14.04 e 16.04 não são EOL. De onde você tirou essa lista?

Provavelmente redação errada. É EOL para nós porque sua versão Qt é menor que nosso requisito mínimo.

OK. Acho que tudo está definido agora, e estou preparando construções. O branch v4_3_x será empurrado junto com as compilações.

@sledgehammer999 Desculpe pelo comentário tardio, mas lembre-se de mencionar (na seção de notícias do site) que houve muitas correções de libtorrent desde o último lançamento que estão presentes neste, incluindo vazamentos de memória conhecidos, problemas de velocidade devido a lógica de configurações de cache defeituosa no Windows, etc. Você pode dar uma olhada no libtorrent 1.2.6-1.2.11 (1.2.11 ainda não foi lançado oficialmente, mas já tem algumas entradas no changelog) para se inspirar e escolher as entradas mais relevantes.

Por curiosidade, qual commit da libtorrent será usado?

OK, e o último git commit como sempre.

@rrrevin

Ubuntu 14.04 e 16.04 não são EOL. De onde você tirou essa lista?
https://wiki.ubuntu.com/Releases

Provavelmente redação errada. É EOL para nós porque sua versão Qt é menor que nosso requisito mínimo.

Bem, eu realmente quis dizer "Fim do suporte padrão", eu acho, que é realmente o que importa de qualquer maneira. Além disso, apenas empresas pagantes recebem suporte. 16.04 ainda não está tecnicamente no "Fim do Suporte Padrão", mas está muito próximo. E, independentemente, o suporte OOTB para ele foi descartado há 2 anos ou mais, devido ao qBittorrent elevando a versão Qt mínima necessária para 5.9.

@ Sledgehammer999 Mais uma coisinha: considere mencionar a regressão menor do menu de contexto da tag conhecida nas notícias: https://github.com/qbittorrent/qBittorrent/issues/13492.

@sledgehammer999 Você não creditou muitos dos meus PRs no changelog... https://github.com/qbittorrent/qBittorrent/pulls?q=is%3Apr+author%3AFranciscoPombal+is%3Aclosed+milestone%3A4.3.0

@FranciscoPombal Combinei todos os seus PRs do CMake em uma entrada. Suas PRs de limpeza de código interno não podem ser mencionadas no Changelog. Ele deve conter correções voltadas para o usuário. O mesmo com os muitos PRs de @Chocobo1
Se eu esqueci de algo específico, por favor mencione abaixo. Vou aguardar alguns instantes, pois ainda faço tarefas administrativas nos bastidores.

@marreta999

Ele deve conter correções voltadas para o usuário.

OK então:

• --> https://github.com/qbittorrent/qBittorrent/pull/13042 é voltado para o usuário, pois corrige um bug de anúncio no rastreador incorporado. <--

• https://github.com/qbittorrent/qBittorrent/pull/12086 , https://github.com/qbittorrent/qBittorrent/pull/13109 e https://github.com/qbittorrent/qBittorrent/pull/13439 não são usuário voltado para limpezas, então eu acho que está tudo bem.

• https://github.com/qbittorrent/qBittorrent/pull/13288 é meio voltado para o usuário, eu acho? Agora os usuários podem baixar compilações experimentais do CI, isso é considerado voltado para o usuário?

• O restante já está creditado, relacionado às melhorias do CMake (já creditado também) ou relacionado a https://github.com/qbittorrent/qBittorrent/pull/13288.

/offtopic (para outro momento) - talvez as limpezas não voltadas para o usuário devam ser incluídas em "OUTROS" ou talvez uma nova seção "CODE HEALTH"? Os usuários gostam de ver esse tipo de coisa no changelog.

--> #13042 é voltado para o usuário, pois corrige um bug de anúncio no rastreador incorporado. <--

Tudo bem, desculpe. Não ficou claro no título do commit. Você pode sugerir uma entrada de registro de alterações apropriada (para usuários que a estão lendo)?

As alterações de IC geralmente são irrelevantes para as versões.

/offtopic (para outro momento) - talvez as limpezas não voltadas para o usuário devam ser incluídas em "OUTROS" ou talvez uma nova seção "CODE HEALTH"? Os usuários gostam de ver esse tipo de coisa no changelog.

Hmm, vou adicionar uma entrada OTHER para limpezas de código creditando você e @Chocobo1

13288 é meio voltado para o usuário, eu acho? Agora os usuários podem baixar compilações experimentais do CI, isso é considerado voltado para o usuário?

IMO, tal coisa pode ser mencionada em Notícias (fora do log de alterações).

IMO, tal coisa pode ser mencionada em Notícias (fora do log de alterações).

Eu poderia de alguma forma enfiar um link "nightlies" na página de downloads ...

~@glassez~ @sledgehammer999

IMO, tal coisa pode ser mencionada em Notícias (fora do log de alterações).

Eu poderia de alguma forma enfiar um link "nightlies" na página de downloads ...

Apenas mencione as coisas de CI nas notícias, eu hesitaria em vincular a página de downloads "noite" a um público mais amplo antes de termos versões baseadas em git nos executáveis. Caso contrário, todos os usuários relatarão todas as diferentes versões noturnas como "4.x.xalpha1", levando a confusão.

versionamento baseado em git nos executáveis. Caso contrário, todos os usuários relatarão todas as diferentes versões noturnas como "4.x.xalpha1", levando a confusão.

Sim, essa é uma observação correta.

@marreta999

Você pode sugerir uma entrada de registro de alterações apropriada (para usuários que a estão lendo)?

"Corrigido a lógica de anúncio quebrada no rastreador incorporado, causando falhas em alguns casos."

As compilações de CI também podem ser usadas para fins maliciosos. Criando relações públicas maliciosas e depois distribuindo links.
Eu recomendaria não vincular tal coisa no site.

@an0n666

As compilações de CI também podem ser usadas para fins maliciosos. Criando relações públicas maliciosas e depois distribuindo links.
Eu recomendaria não vincular tal coisa no site.

Este também é um bom ponto. Acho melhor começar a trabalhar no fluxo de trabalho especificamente para compilações noturnas que apenas compilam a partir do mestre sobre o qual falei antes. Então, poderemos vincular a compilações noturnas sem medo de que isso aconteça.

A liberação é feita.
O PPA será limpo amanhã.
Detalhes do problema de segurança em alguns dias.
Plano de mudanças organizacionais em poucos dias.

E como sempre um obrigado a todos por suas contribuições neste ciclo de lançamento.