Para mais informações sobre todas as alterações lançadas na versão 2026.7, confira:
Lançamentos de correções para outras versões suportadas também foram disponibilizados:
4 curtidas
Isso se torna a versão atual “esr” ou eu entendi algo errado?
1 curtida
De fato, não consigo entender o que aconteceu. Para esta atualização (muito urgente devido a Cache poisoning/XSS via color scheme cookies · Advisory · discourse/discourse · GitHub), era necessário um rebuild, mas como havia um changelog v2026.1.5 → v2026.1.6, assumi que seria um incremento menor de versão. Mas não, agora estou na v2026.7.0. Pelo que sei, meu fórum está configurado para estar no esr :
params:
db_default_text_search_config: "pg_catalog.english"
## Defina db_shared_buffers para no máximo 25% da memória total.
## será definido automaticamente pelo bootstrap com base na RAM detectada, ou você pode substituir
db_shared_buffers: "2048MB"
## pode melhorar o desempenho de ordenação, mas aumenta o uso de memória por conexão
db_work_mem: "40MB"
## Reduzir o tamanho máximo de upload
upload_size: 1m
## Qual revisão Git este container deve usar? (padrão: tests-passed)
version: esr
Também fiquei bastante surpreso ao ver uma série inteira de consultas de pós-atualização como esta:
== 20260421061908 AddCoveringIndexOnChatMessagesThreadId: migrating ===========
-- remove_index(:chat_messages, {name: "idx_chat_messages_thread_id_id_user_id_not_deleted", algorithm: :concurrently, if_exists: true})2026-07-28 16:02:43.673 UTC [544] discourse@discourse LOG: duration: 16903.716 ms statement: CREATE INDEX CONCURRENTLY "index_posts_on_updated_at_for_localization" ON "posts" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NOT NULL
2026-07-28 16:02:59.214 UTC [544] discourse@discourse LOG: duration: 15529.318 ms statement: CREATE INDEX CONCURRENTLY "index_posts_on_updated_at_for_locale_detection" ON "posts" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NULL
2026-07-28 16:03:00.031 UTC [544] discourse@discourse LOG: duration: 798.943 ms statement: CREATE INDEX CONCURRENTLY "index_topics_on_updated_at_for_locale_detection" ON "topics" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NULL
2026-07-28 16:03:00.186 UTC [544] discourse@discourse LOG: duration: 143.500 ms statement: CREATE INDEX CONCURRENTLY "index_topics_on_updated_at_for_localization" ON "topics" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NOT NULL
2026-07-28 16:03:01.251 UTC [544] discourse@discourse LOG: duration: 1051.872 ms statement: UPDATE posts
SET raw = regexp_replace(
raw,
'\\+([_*~|`])(?=[^\]\[]*\]\(upload://)',
'\1',
'g'
)
WHERE id >= 1
AND id < 10001
AND raw ~ '\\+[_*~|`][^\]\[]*\]\(upload://'
2026-07-28 16:03:01.910 UTC [544] discourse@discourse LOG: duration: 658.965 ms statement: UPDATE posts
SET raw = regexp_replace(
raw,
'\\+([_*~|`])(?=[^\]\[]*\]\(upload://)',
'\1',
'g'
)
WHERE id >= 10001
AND id < 20001
AND raw ~ '\\+[_*~|`][^\]\[]*\]\(upload://'
2 curtidas
Sim, é isso mesmo!
Este lançamento é uma nova versão ESR, então você migrou para ela quando fez a atualização.
3 curtidas
No futuro, isso poderia ser tornado menos confuso de alguma forma? Talvez seja só eu, mas se uma atualização for aplicada ao ramo ESR em que estou atualmente, assumo que seja porque a versão principal atual desse ramo ainda é suportada.
2 curtidas
A versão 2026.1 ainda é suportada, e você pode fixar sua instalação nela definindo version: release/2026.1 no seu app.yml. Nesse caso, executar uma reconstrução teria aplicado a atualização de segurança na branch 2026.1.
Acho que você estava usando version: esr? Nesse caso, você está acompanhando a versão ‘mais recente do ESR’, que agora é 2026.7.
Você pode encontrar informações sobre os períodos de suporte e as sobreposições entre os suportes ESR em https://releases.discourse.org/
Infelizmente, não é possível fazer downgrade do Discourse. Mas, se quiser evitar isso no futuro, você pode fixar na versão release/2026.7 (e certifique-se de atualizar esse fix manualmente antes que o suporte à 2026.7 termine).
1 curtida
Obrigado. Acho que estou procurando a maneira mais à prova de falhas/automatizada para definitivamente permanecer na versão mais antiga que ainda é suportada, ou seja, o caminho de desenvolvimento mais lento.
3 curtidas
Aqui também, e acho que o esr (quase) faz isso. A cada poucos meses, há um novo esr e você migra para ele, o que acabou de acontecer. Mas, na verdade, o esr antigo tem mais dois meses de vida útil mantida, então você esperava permanecer nesse esr anterior. (Acho que é razoável querer fazer isso. Precisamos de um rótulo esr-mantido??)
4 curtidas
Acho que é algo razoável considerar, mas pense também nisso… o que seria diferente daqui a 2 meses, quando a v2026.1 deixar de ser mantida?
Sem alterações adicionais, você ainda seria atualizado naquele momento “sem aviso”.
Isso está OK?
1 curtida
Sim, acho que ainda faz sentido querer permanecer na versão ESR antiga por mais tempo. Isso significa que a nova ESR passou por alguns testes e pode ter recebido algumas correções.
Eu atualizei para a nova ESR dentro de uma hora e me arrependo um pouco: no mundo atual, o melhor conselho seria fixar a versão anterior e receber apenas as correções de segurança. Isso separa a correção de segurança urgente da curva de aprendizado administrativa e de quaisquer novos bugs que serão corrigidos em breve. Veja o muito útil
Salto da ESR 2026.1 para 2026.7 - O que encontrei
(Por que esperar novos bugs em uma ESR recém-lançada? Porque, pelo que posso ver, a nova ESR estava em desenvolvimento contínuo até o momento do lançamento. Não há fase de estabilização.)
2 curtidas
Essa é a grande questão.
Então, se eu estivesse na esr-maintained, depois de dois meses, esr e esr-maintained seriam a mesma branch, certo? Então, após 2 meses, eu ainda ficaria surpreso com a grande mudança.
Enquanto esr e esr-maintained não forem a mesma branch, o Discourse poderia emitir/exibir um aviso de que você entrou no “período de carência ESR”. Esse aviso poderia ser mostrado apenas no fórum para administradores, e não ao reconstruir o container.
Ter um aviso prévio sobre a rolagem do ESR seria bom, para que você possa planejar e testar a atualização durante esse período de carência suportado.
4 curtidas
Em um mundo ideal, isso lhe dá dois meses para atualizar seu servidor de staging para o novo ESR, enquanto em Produção você pode continuar executando o antigo ESR com atualizações de segurança para cobrir esse período.
De fato, faz sentido ter algum tipo de rastreamento de rótulos simples para acompanhar o antigo ESR corrigido, assim você recebe automaticamente as atualizações mantidas do antigo ESR.
Talvez já exista uma maneira de alcançar isso?
2 curtidas
Não acho que o ESR receberá tantas correções de bugs. Assim como a versão 2026.1, ele receberá apenas correções de segurança a partir de agora.
Portanto, embora alguns desses bugs possam se tornar conhecidos em um mês, isso não significa que você não precise lidar com eles.
3 curtidas
Adotando uma postura pessimista, vamos ver! Imagino que, se alguma mudança disruptiva tola fosse encontrada em um ESR recém-lançado, ela seria corrigida. Talvez esse novo cenário ainda não esteja estabelecido há tempo suficiente para que isso aconteça. De fato, não esperaria correções para meros inconvenientes.
1 curtida