Alternando entre canais/versões de lançamento do Discourse

[Discourse]

Este guia explica como configurar o canal de lançamento da sua instância Discourse.

Nível de usuário necessário: Administrador do Sistema

É necessário acesso ao console.

Gerenciar o canal da sua instância Discourse determina a frequência e o tipo de atualizações que você recebe. Este guia explica os canais disponíveis e fornece uma abordagem passo a passo para alterar a branch na sua configuração.

Resumo

O Discourse oferece vários canais para acompanhar as atualizações de software: latest, release e esr. Esta documentação explica o propósito de cada um, suas principais características e como configurá-los na sua instância Discourse. Para uma ilustração dos canais, consulte releases.discourse.org.

Canais suportados

latest

Padrão Recomendado
Este canal fornece as correções de bugs mais recentes e atualizações de compatibilidade para plugins. Cada commit aprovado da branch main é testado pelo servidor de compilação e adicionado à branch latest após verificação bem-sucedida.

• Adequado para sites que desejam permanecer atualizados.
• Os sites podem atualizar manualmente a qualquer momento.

release

Para Sites que Preferem Lançamentos Mensais

O canal release acompanha o lançamento mensal mais recente do Discourse. Todo mês, uma branch de lançamento (por exemplo, release/2026.2) é criada a partir do latest, fornecendo uma versão estável.

• Lançado aproximadamente uma vez por mês.
• Cada lançamento recebe correções críticas por dois ciclos completos de lançamento.

esr

Lançamento com Suporte Estendido

A tag esr acompanha o Lançamento com Suporte Estendido mais recente, destinado a sites que priorizam estabilidade e segurança de longo prazo em vez de atualizações frequentes.

• Declarado aproximadamente a cada 6 meses a partir dos lançamentos mensais.
• Recebe correções de segurança e backports críticos por um período estendido.
• Pode ter compatibilidade limitada com plugins da comunidade e componentes de tema.

Nota: Não receber atualizações de manutenção regulares pode deixar alguns recursos desatualizados ou visualmente inconsistentes.

Aliases obsoletos

Para compatibilidade com versões anteriores, os seguintes nomes antigos de branch/tag ainda funcionam, mas são considerados obsoletos:

• tests-passed → latest
• beta → release
• stable → esr

Outras branches ou referências

Acompanhar outras branches (por exemplo, branches específicas release/AAAA.M ou SHAs de commit) é possível, mas requer conhecimento técnico. Essas branches recebem apenas correções críticas por um período limitado.

Instruções para configurar seu canal

Siga estas etapas para configurar a branch desejada na sua instância Discourse:

1. Acesse o arquivo de configuração
   Abra o arquivo de configuração app.yml executando os seguintes comandos no seu console:

cd /var/discourse
nano containers/app.yml

O editor nano abrirá o arquivo de configuração.
2. Edite a branch de acompanhamento
Localize o parâmetro de versão pesquisando pela palavra “version” no arquivo:

params:  
## Which Git revision should this container use? (default: latest)  
#version: latest

• Descomente a linha da versão.
• Substitua latest pelo nome da branch ou tag desejada (por exemplo, esr). Exemplo:

params:  
## Which Git revision should this container use? (default: latest)  
version: esr  

3. Salve e saia

• Pressione Ctrl+O para salvar suas alterações.
• Pressione Enter para confirmar.
• Use Ctrl+X para sair do editor.

4. Reconstrua o container
   Depois que as alterações forem feitas e salvas, reconstrua o container para aplicar a nova configuração:

./launcher rebuild app

A reconstrução causará tempo de inatividade temporário

[ghorbani (Aref)]

@Discourse

cd /var/discourse
git pull
nano containers/app.yml

O comando git pull é um passo necessário, ou é redundante e permanece da documentação antiga, assim como no caso da atualização do Discourse (Atualizar manualmente o Discourse e a imagem Docker para a versão mais recente)?

[merefield (Robert)]

Na minha experiência, git pull é ocasionalmente útil — por exemplo, foi essencial quando migramos do yarn para o pnpm …

Normalmente, você não precisa se preocupar com isso para uma reconstrução regular.

[ghorbani (Aref)]

Bom saber! Obrigado pela informação.

[merefield (Robert)]

o que eu geralmente faço é tentar reconstruir, e se falhar por algum motivo não muito óbvio, tento primeiro um git pull - leva um momento.

[david (David Taylor)]

Em teoria, isso nunca deveria ser necessário. O launcher detectará automaticamente uma cópia desatualizada e executará o git pull por conta própria:

launcher

[ghorbani (Aref)]

Obrigado pelos detalhes. De fato, faz sentido. Vou tentar sem git pul e te aviso como foi.

[Ed_S]

Isso é estranho. O código em questão é de 2015, meu fórum é de 2018, e ainda assim tenho certeza de que já houve várias instâncias discutidas aqui onde era necessário fazer um git pull.

No meu caso, sempre faço git pull, se me lembrar - isso não me custa nada.

[david (David Taylor)]

Isso é mencionado com frequência, acho que por causa desses documentos muito históricos. Eu não acho que já vi alguma evidência de que realmente ajudou.

Mas sim, não há mal nenhum em executá-lo manualmente também

[Ed_S]

@Discourse

## Qual revisão do Git este contêiner deve usar? (padrão: latest)  
#version: latest

Como o arquivo yml usa version e não supported tracking branch, seria bom adicionar (version) ao título do tópico?

[ghorbani (Aref)]

Eu também fiquei um pouco surpreso com a data no início. Mas, verificando o histórico de versões, a última atualização é de 18 de maio.

[david (David Taylor)]

Tentei atualizar a publicação original para usar nossa terminologia moderna de “canal” e remover algumas referências desnecessárias ao git pull.

[merefield (Robert)]

Deve haver pelo menos um caso limite, porque definitivamente “me ajudou a superar o obstáculo” em ocasiões muito raras

Será que acontece quando o script principal muda em circunstâncias limitadas?