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.