Olá,
Aqui está a ideia que não sai da minha cabeça: a maior parte da frustração com a “nova versão disponível a cada commit” vem do fato de que o canal latest é atualizado continuamente, então estar alguns commits atrás é, na verdade, o estado de repouso normal, mas a página trata isso como se houvesse um problema. Em vez de redesenhar tudo, eu focaria em distinguir o sinal do ruído.
Do jeito que eu imagino, a página teria um banner de status que muda de significado dependendo de onde você realmente está:
- Atualizado → discreto, positivo, sem chamada para ação.
- Alguns commits atrás do
latest→ cinza/informativo, e diz explicitamente nenhuma ação necessária. Este é o estado que atualmente “grita” e realmente não deveria. - Uma nova versão mensal está chegando (ex:
v2026.8.0) → em destaque, com um link para as notas de lançamento. - Atualização de segurança → vermelho/urgente, destacado separadamente.
Apenas os dois últimos deveriam parecer algo que exija sua atenção.
Algumas outras coisas que eu gostaria de ver lá:
- O número da versão, em destaque novamente. Apenas um pequeno cartão com a versão instalada, o hash do commit e o canal (ex:
v2026.8.0-latest.1 · dfe770d · latest). Esta é a reclamação mais comum que já vi e é fácil de trazer de volta. - Aproveitar a verificação em cache que já temos. A verificação de versão já é executada como um job periódico do Sidekiq, em vez de ao vivo por requisição, então a página não precisa parecer lenta; ela pode renderizar esse resultado em cache imediatamente com uma linha “última verificação há X minutos” e um botão “verificar agora” manual, em vez de parecer que está recalculando ao carregar.
- Um histórico de atualizações com links para o changelog basicamente a ideia original deste tópico. Uma linha do tempo curta de lançamentos (mensais + ESR), cada um com link para seu changelog ou diff.
Sobre componentes e reconstruções: o que eu mais gostaria de ver explicitado é a divisão entre as atualizações que o atualizador web pode aplicar sozinho (núcleo + plugins, via git pull) e aquelas que alteram o container e, portanto, precisam do comando ./launcher rebuild app na linha de comando. Uma lista por componente, onde cada linha mostra a qual categoria pertence, ajudaria muito, e para o caso de reconstrução, poderia mostrar o comando exato com um botão de copiar, em vez de deixar você adivinhar.
Sobre compatibilidade de plugins: o mecanismo .discourse-compatibility já lida com o caso em que seu núcleo é mais antigo do que o que um plugin agora exige; ele verifica silenciosamente o último commit compatível desse plugin durante uma reconstrução. Isso afeta principalmente instalações estáveis/ESR e hoje acontece em silêncio. Seria bom exibir isso como uma linha informativa simples “mantido em uma versão compatível”, para que administradores de versões mais antigas possam ver por que um plugin não está em seu commit mais recente. (O caso oposto, um plugin que ainda não suporta um núcleo mais novo, não é realmente tratado hoje; há uma solicitação de recurso aberta sobre versões mínimas/máximas compatíveis que cobriria isso.)
Juntei rapidamente um mock interativo para ver como os diferentes estados ficam lado a lado — honestamente, o maior ganho é apenas o estado “você está atrás, mas tudo bem”. Uma vez que isso deixa de ser um alarme, a página se torna genuinamente útil novamente. Fico feliz em compartilhar o mock se alguém quiser dar uma olhada.