Atualizando / Reconstruindo Container Docker resulta em v3.5.2 em vez de v2025.11.0

Instalação
1

Atualizamos uma instalação existente do Discourse como fizemos várias vezes antes: depois de puxar a revisão atual do repositório discourse_docker, executamos o seguinte comando:

./launcher rebuild app

Ele é executado sem erros e também inicia o novo contêiner - parece tudo bem.

Mas ao examinar o código-fonte HTML da aplicação em execução, vemos que ela ainda alega ser uma v3.5.2 (a versão anterior à atualização) - em vez da v2025.11.0 esperada.

Nosso procedimento é o mesmo das atualizações anteriores. A única coisa que mudou visivelmente é o esquema de numeração de versão introduzido com a v2025.11.0 - talvez esteja relacionado a essa mudança?

Verifiquei se no código-fonte do Discourse a string de versão foi, por exemplo, esquecida de ser atualizada, mas não é o caso, veja os dois commits:

A partir da saída do comando de reconstrução do launcher, notei que ele executa um git pull e vê/detecta os novos branches:

(...)
 t [tag update]          beta                    -> beta
 t [tag update]          latest-release          -> latest-release
 * [new tag]             release                 -> release
 * [new tag]             v2025.11.0              -> v2025.11.0
 * [new tag]             v2025.12.0-latest       -> v2025.12.0-latest
 * [new tag]             v3.5.2                  -> v3.5.2
 * [new tag]             v3.6.0.beta2            -> v3.6.0.beta2
Switched to a new branch 'stable'
I, [2025-12-03T12:27:14.785550 #1]  INFO -- : branch 'stable' set up to track 'origin/stable'.

Ainda assim, de alguma forma, parece que ele está pegando o branch errado (no sentido de “não o mais recente”). O branch “stable” parece conter a v3.5.2 (de acordo com lib/version.rb nesse branch).

Relendo o Anúncio de Lançamento para 2025.11.0 e realmente parece um lançamento estável, não apenas uma prévia/lançamento para adotantes iniciais. A nova estratégia de versionamento vinculada menciona o branch latest, mas agora estou ainda mais confuso sobre o que esperar.

Estou perdendo alguma coisa? Ou podemos influenciar qual versão é selecionada durante a reconstrução? Ou simplesmente não está funcionando como pretendido no momento e a ferramenta de reconstrução precisa de uma alteração?

Não sei se está relacionado, mas no Docker hub, a tag “latest” é 3.5.2 - e ordenando numericamente de forma decrescente, esta pode ser a tag mais recente por um bom tempo…

1 curtida
2

v3.5.x é a versão correta para o branch estável :+1:

2025.11.0 é um ‘lançamento’ mensal, mas não um lançamento ‘estável’/‘esr’. (em breve mudaremos o nome de estável para esr, como parte da nova estratégia de versionamento)

1 curtida
3

Isso é confuso. Faria mais sentido mudar todos para o novo esquema de versão de uma vez, mas também não faz sentido o estável ser atualizado quando não há um novo estável. Fiquei confuso, e gosto de pensar que estou prestando atenção nisso. Lembro-me de alguma discussão do Richard sobre isso, mas não prestei atenção suficiente para entender.

:person_shrugging:

4

Obrigado @david - isso pelo menos ajuda, pois agora entendo que não fiz nada de errado.

Resta-nos o problema de como decidir o que é um “lançamento mensal” e o que é um “lançamento estável”?

Nós buscamos o Feed Atom do Github (para ser notificado sobre lançamentos recém-detectados) e o 2025.11.0 e o 3.5.2 aparecem da mesma forma (junto com muitas outras tags).

Então, como/onde podemos descobrir facilmente a intenção da sua equipe para uma determinada tag de versão?

Concordo com @pfaffman, está muito confuso no momento.

5

Sim, eu entendo — estamos em uma fase de transição entre dois esquemas de numeração/nomenclatura, então as coisas estão um pouco difíceis de acompanhar.

Estamos trabalhando na criação de uma página que lista todas as versões atualmente suportadas e seus changelogs (registros de alterações). Algo como isto. Esperamos que isso ajude com perguntas como esta.

A partir de janeiro de 2026, marcaremos um lançamento com a tag ‘esr’. Essa será a substituta para a cadência de 6 meses da versão ‘stable’ atual.

Então, beta se tornou release (nunca foi realmente ‘beta’, era apenas um ponto de verificação mensal)

E stable se tornará esr, mas isso ainda não aconteceu

Portanto, se você deseja uma cadência de 6 meses, deve se ater a stable por enquanto e, em seguida, usar esr a partir de janeiro.

Se você deseja uma cadência mensal, pode direcionar a tag release.

1 curtida
6

Bem, mentes brilhantes pensam da mesma forma, pois era exatamente isso que eu estava esperando!

1 curtida
7

Eu entendo perfeitamente e meu feedback e perguntas não foram feitos com a intenção de ofender.

Nós atualizamos, por exemplo, de 3.5.0, passando por 3.5.1 para 3.5.2 no passado. Eu não sei se isso era “stable” ou “latest” ou como quer que fosse chamado no esquema antigo ou agora no novo esquema. Eu estou de acordo com a mudança no esquema de versionamento e lançamento - mas não estou perto o suficiente do projeto/produto para ter entendido ou querer entender todos os detalhes do novo esquema de versionamento e lançamento.

Obrigado pela sua reação muito rápida e pela dica útil de que 3.5.2 ainda está bom para ser usado, isso ajudou.

E:

Obrigado @david - isso parece muito bom! Estamos ansiosos para ver esta página disponível - ela deve simplificar muito nosso procedimento de atualização!

2 curtidas