Temos debatido internamente algumas ideias sobre como melhorar a página “update discourse”.
Uma das ideias é mostrar o histórico de atualizações, com links para os changelogs das diferenças entre elas (o que poderia ser útil para entender as mudanças que você observa após fazer uma atualização).
Aqui estão outras algumas ideias / reclamações que acabaram de surgir:
Quais outras ideias as pessoas têm?
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á:
latest → cinza/informativo, e diz explicitamente nenhuma ação necessária. Este é o estado que atualmente “grita” e realmente não deveria.v2026.8.0) → em destaque, com um link para as notas de lançamento.Apenas os dois últimos deveriam parecer algo que exija sua atenção.
Algumas outras coisas que eu gostaria de ver lá:
v2026.8.0-latest.1 · dfe770d · latest). Esta é a reclamação mais comum que já vi e é fácil de trazer de volta.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.
Boa ideia.
Apenas uma esclarecimento sobre esta parte:
Estou pensando que isso seria sobre as atualizações que você fez, não necessariamente os “lançamentos” que fazemos.
Então, cada vez que você fizer uma atualização, uma nova linha aparecerá. Pode ser para 5 commits dentro de um lançamento. Ou pode ser de 2026.1.6 → 2026.7.1 se você esperar pelo primeiro lançamento de patch após o próximo ESR ser feito para atualizar.
De qualquer forma, isso deve mostrar o histórico das atualizações que você fez no seu site anteriormente e o conjunto de mudanças entre elas.
Adicione algo em destaque sobre a importância de fazer um backup primeiro!
Adicione algo sobre como, se a atualização falhar, a reconstrução do launcher na CLI é o próximo passo. Pelo menos uma nota de que as atualizações às vezes falham e isso deixará o fórum offline.
Idealmente, uma maneira de sinalizar que as alterações pendentes incluem algo importante, como a atualização da versão do banco de dados que ocorreu recentemente e que foi, na última vez que aconteceu, realmente um evento importante, em termos do número de tópicos iniciados aqui para suporte. Se bem que me lembre.