Para mais informações sobre todas as alterações lançadas na 2026.1, consulte:
Esta é a primeira versão “ESR” (Extended Support Release) do Discourse e substitui o antigo branch “stable” (estável). Os sites que acompanham o estável serão atualizados da 3.5 para a 2026.1 em sua próxima atualização. Para ver todas as alterações da 3.5 para a 2026.1, use este link.
Versões de correção (patch releases) para outras versões suportadas também foram lançadas:
2026.1.0 sendo também a primeira versão esr (suporte de longo prazo).
Para as pessoas no branch stable (ramo estável) previamente existente (que agora é um alias para esr), a atualização será de 3.5.3 para 2026.1.0; e não para 3.5.4.
Então, deixe-me ver, eu tenho até abril para não atualizar (3 meses) quando a v2026.1 for descontinuada, minha versão atual será ESR, certo? Todas essas mudanças estão um pouco confusas.
Sim, a menos que estejam usando a tag v3.5.4 para se manterem na 3.5.
O diagrama na página inicial de https://releases.discourse.org/ é a melhor maneira de visualizar as coisas.
Qualquer fluxo de lançamento que você escolher, você sempre precisará atualizar regularmente para correções de segurança críticas. A questão é se você também quer obter novos recursos e outras mudanças junto com as correções de segurança (se sim, use release ou latest), ou se prefere ter uma cadência de seis em seis meses para isso (se sim, use esr).
Ainda é o começo para este novo esquema de numeração, então a documentação e as ferramentas continuarão a evoluir à medida que crescermos no novo sistema.
Era a v2026.0 quando atualizei pela última vez em dezembro e agora a v2026.2 se tornará ESR em abril, certo?
Confira a página inicial do releases.discourse.org para todas as informações de suporte. 2026.1 é a versão de suporte estendido atual e será suportada até outubro de 2026.
O 2026.2 será lançado em fevereiro e receberá correções de segurança por 2 meses após isso. Não será uma versão de suporte estendido.
A versão 2026.1.0 é a primeira versão estável/ESR a remover o suporte para iOS e outros navegadores antigos? Essa é uma mudança grande o suficiente para ser listada em algum lugar nas notas de lançamento. Eu não consegui encontrar nada sobre isso na caixa de pesquisa de “mudanças detalhadas” no final, no entanto.
Ah, eu acho que é porque você vinculou ao changelog de v2026.1.0-latest → v2026.1.0. Se você mudar para v3.5.3 → v2026.1.0 então ele mostra 2397 mudanças detalhadas, em vez de apenas 369. Para essas versões ESR, você realmente deveria estar vinculando para a última versão ESR em vez de -latest (isso é como um RC?)
Eu ainda não consigo ver qual mudança marcou claramente a remoção do suporte para os navegadores antigos, mas pelo menos consegui encontrar esta: FIX: Update 'modern mobile' regex following iOS 15 support drop by davidtaylorhq · Pull Request #34792 · discourse/discourse · GitHub
Sim 
Sim. A grande maioria das pessoas usa os canais latest ou release do Discourse, então é para isso que o site do changelog é otimizado. Pessoas que escolhem ESR estão essencialmente ‘pulando 5 versões’ a cada atualização, então você precisaria ver as mudanças para cada uma dessas versões intermediárias.
Você pode fazer isso navegando em cada changelog intermediário, ou pode usar os filtros para gerar um changelog personalizado que abranja todo o intervalo (como você fez). Talvez possamos melhorar a experiência do usuário do site de lançamentos para ter algum tipo de link rápido para pular para uma comparação ESR → ESR.
Olhando para trás, para o último lançamento ‘estável’, também não tínhamos um ‘mega-changelog’ para ele. As pessoas tiveram que ler cada um dos changelogs beta intermediários para ter uma visão completa das mudanças. Então, acho que estamos caminhando na direção certa aqui - pelo menos agora é possível ver um changelog completo, mesmo que a experiência do usuário não seja a mais suave.
Por enquanto, adicionei um link para essa comparação ESR → ESR no OP aqui:
Obrigado pelo feedback!
Seja de uma versão específica para outra ou de um ponto arbitrário em latest para o latest mais recente, se uma alteração entre os commits x e y não puder ser aplicada pelo atualizador integrado, exigindo em vez disso que o contêiner seja reconstruído a partir de uma nova imagem, o novo sistema de notas de lançamento identificará isso e observará a necessidade de uma reconstrução?
Separadamente, o atualizador integrado impedirá a atualização, solicitando uma reconstrução?
Minha compreensão superficial do atualizador integrado é que, após atualizar o Docker_manager, ele bloqueará a atualização do Discourse se uma reconstrução for necessária. No entanto, não vi isso formalizado e, anedoticamente, não pareceu totalmente confiável.
Especificamente, às vezes, navegar da atualização concluída do Docker_manager para a página de Versões mostrará a atualização do Discourse disponível para iniciar, e só depois de atualizar a página ela será bloqueada. [Observarei que a última vez que vi isso acontecer foi há muito tempo, talvez tenha sido corrigido.]
A necessidade de reconstrução está relacionada à ‘imagem base do Docker’ do Discourse, que é totalmente desacoplada do número da versão do Discourse. Nós a exigimos quando há alterações críticas nas dependências de nível de sistema operacional dentro da imagem do docker.
Portanto, seria complicado incluí-la nas notas de lançamento do núcleo do Discourse. Mas eu entendo sua frustração por não conseguir atualizar pela interface do usuário (UI). Talvez possamos fazer melhorias na UI nesse aspecto.
Eu poderia imaginar isso funcionando por:
Dito isso, ainda temos outras coisas mais importantes para resolver agora que são mais importantes para o trabalho de versionamento em geral (por exemplo, a compatibilidade de componentes de tema/plugins).
Ah, eu acho que não poder usar sempre a interface do usuário para atualizar é aceitável, e qualquer pessoa (indivíduo, empresa, o que for) que hospeda o Discourse deve (deveria) ter alguém disponível com pelo menos habilidades básicas de administração de servidor para poder realizar tarefas como manter o sistema host atualizado e reconstruir o Discourse.
As coisas mais importantes na minha opinião são:
Desde que a interface do usuário sempre se atualize corretamente após a atualização do docker_manager, ou seja, não acabe em um estado em que saiba que o docker_manager está atualizado, mas não saiba que uma reconstrução é necessária, acho que ambas as coisas já são verdadeiras.