Tenho um sistema de longa duração, nunca tive problemas antes. Sempre faço a atualização com uma reconstrução completa, nunca usando a atualização integrada.
Recentemente, fiz um apt-get upgrade, atualizei o Docker para a versão 19.03.5 e tentei uma reconstrução, mas agora está quebrado. O sistema é Ubuntu 16.04.6.
@j.jaffeuxDiscourse.redis deve ser portado para trás para stable e beta? Acredito que isso seria mais fácil do que adicionar código para compatibilidade retroativa em vários plugins.
Tenho quase certeza de que as alterações mais recentes quebram o docker_manager, pois ele é atualizado antes do Discourse e, portanto, não encontra Discourse.redis.
Resumo curto: o tests-passed funcionou, tive 1 dia de indisponibilidade.
Versão mais detalhada: Acredito que este seja um dos softwares de código aberto de maior qualidade escritos na internet hoje, com um modelo de negócios sólido e uma equipe excelente. Como é que o mecanismo de atualização está tão quebrado?
O recurso de atualização no aplicativo me causou tantas indisponibilidades que decidi não usá-lo de forma alguma, optando sempre por fazer uma reconstrução.
Mas, como você pode ver neste tópico, nas duas vezes recentes a reconstrução também resultou em um aplicativo muito quebrado, algo que eu não conseguiria corrigir sozinho, a não ser recorrendo ao tests-passed com base nas recomendações aqui.
Por que o mecanismo de atualização está tão quebrado em um software tão bem escrito? Por que tenho sites WordPress com mais de 5 anos funcionando sem problemas com o mecanismo de atualização integrado?
Qual é o sentido de ter releases no Discourse se literalmente não há como usá-las? Uma reconstrução é sempre feita a partir de uma branch do git, e as releases não têm nada a ver com git.
Para mim, uma release seria ou um tag do git ou um arquivo zip. Por que não posso simplesmente usar a reconstrução com a versão 2.3.x, como faria com qualquer gerenciador de pacotes moderno hoje em dia?
Como se vê, tests-passed é o que o discourse.org implanta em seus servidores e é mais testado e confiável do que stable. Se você permanecer em tests-passed, terá menos problemas. Se quiser executar stable, precisa entender que isso exigirá mais trabalho do que executar tests-passed, como rodar um servidor de staging para testar atualizações antes de aplicá-las em produção.
Eu só quero algo que seja estável e confiável, e baseado em
tests-passed é o que o discourse.org implanta em seus servidores, e é mais testado e mais confiável do que o stable
Vou continuar usando isso. Duas coisas ainda são muito estranhas:
Por que isso é chamado de test-passed e não de stable, se é realmente estável? “stable” poderia ser renomeado para algo como “legacy”.
O sistema de lançamentos ainda não faz sentido. Se estamos construindo a partir de uma branch do Git, qual é o propósito de fazer lançamentos? Gostaria de poder me manter na versão 2.3.x até que a 2.4.x amadureça, por exemplo, e acredito que com o modelo do Discourse isso não é possível de forma alguma.
Com todo respeito, mas discordo disso. O stable é muito confiável e, bem, estável. O Rubygems atualizou uma dependência que fez com que ambos o tests-passede o stable falhassem, e resolver isso foi apenas uma questão de backportar uma correção.
Aliás, isso poderia ter sido evitado fixando o Rubygems em uma versão específica no comando gem update. gem update --system 3.0.6 teria sido seguro.
O fato de o stable ter ficado quebrado por mais tempo que o tests-passed é apenas uma coincidência e, pelo que me lembro, uma primeira vez.
Temos feito isso (manter o stable como padrão) há mais de seis anos, com centenas de instâncias do Discourse, sem problemas significativos.
Apenas neste tópico, há vários momentos em que a versão estável foi reconstruída em um estado quebrado; definitivamente não é a primeira vez. Se as instâncias comerciais do discourse.org estiverem aprovadas nos testes, vou me ater a elas.
Temos feito isso (manter a versão estável como padrão) há mais de seis anos, com centenas de instâncias do Discourse, sem problemas significativos.
Manter-se na versão estável e manter-se na 2.3.x são coisas muito diferentes. Por exemplo, a versão estável não permite que você permaneça na 2.3.x até que a 2.4.x amadureça o suficiente. Por exemplo, com tudo em produção, prefiro não atualizar até que a versão x.x.3 ou x.x.4 seja lançada. Isso, acredito eu, não é possível hoje.
Sei que é verdade, mas você não é um administrador do Discourse comum. Você me salvou várias vezes e, por regra, leio tudo o que você diz duas vezes para garantir que me lembre, mas ainda acho que, para a maioria das pessoas normais, o mais seguro é manter a versão tests-passed.
Você pode usar um ID de commit do git em vez de uma tag.
Mas, mesmo que eu faça isso, isso não me salvará em situações em que a versão estável estiver quebrada, certo? Em ambos os casos, o problema foi um backport ausente, e isso também estaria ausente em qualquer ID de commit do git, acredito.
Portanto, não existe algo como uma “versão” do Discourse onde você baixa um arquivo zip estilo WordPress ou usa um gerenciador de pacotes como yarn/pip/gem, simplesmente porque o Discourse não é lançado, mas sim “reconstruído”, sempre usando versões ao vivo de pacotes externos.
Você me salvou várias vezes e, por regra, leio tudo o que você diz duas vezes para garantir que me lembre, mas ainda acho que, para a maioria das pessoas normais, o mais seguro é manter a versão tests-passed.