2026.7에 포함된 모든 변경 사항에 대한 자세한 내용은 다음을 참고하세요:
기타 지원되는 버전의 패치 릴리스도 함께 발표되었습니다:
이것이 현재 “esr” 릴리스가 되는 건가요, 아니면 제가 뭔가 잘못 이해한 건가요?
2개의 좋아요
실제로 무슨 일이 일어났는지 도무지 알 수가 없습니다. 이 업데이트는 https://github.com/discourse/discourse/security/advisories/GHSA-qx4v-rg4v-pm2g 때문에 매우 시급했는데, 재빌드가 필요했습니다. 하지만 v2026.1.5 → v2026.1.6 변경 이력(changelog)이 있어 사소한 버전 업데이트일 것이라고 생각했습니다. 하지만 아니었습니다. 지금은 v2026.7.0에 있습니다. 제가 아는 한 제 포럼은 esr으로 설정되어 있습니다 
params:
db_default_text_search_config: "pg_catalog.english"
## Set db_shared_buffers to a max of 25% of the total memory.
## will be set automatically by bootstrap based on detected RAM, or you can override
db_shared_buffers: "2048MB"
## can improve sorting performance, but adds memory usage per-connection
db_work_mem: "40MB"
## Reduce max upload size
upload_size: 1m
## Which Git revision should this container use? (default: tests-passed)
version: esr
아래와 같은 게시글 업데이트 쿼리가 대량으로 실행되는 것도 꽤 놀랐습니다:
== 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개의 좋아요
네, 맞습니다!
이 릴리스는 새로운 ESR 릴리스이므로 업데이트를 통해 해당 버전으로 전환되었습니다.
4개의 좋아요
앞으로 이런 혼란을 줄일 수 있는 방법이 있을까요? 저만의 생각일 수도 있지만, 현재 제가 사용 중인 ESR 브랜치에 업데이트가 적용된 것은 해당 브랜치의 현재 메이저 버전이 여전히 지원되고 있기 때문이라고 가정합니다.
2개의 좋아요
2026.1은 여전히 지원되며, app.yml에서 version: release/2026.1으로 설정하면 해당 버전으로 고정할 수 있습니다. 이 경우 재빌드(rebuild)를 실행하면 2026.1 브랜치의 보안 업데이트가 적용되었을 것입니다.
version: esr을 사용하셨던 것 같습니다. 이 경우 ‘최신 ESR’ 버전을 추적하게 되며, 현재 이는 2026.7입니다.
지원 기간 및 ESR 지원 기간의 중첩에 대한 정보는 https://releases.discourse.org/ 에서 확인하실 수 있습니다.
불행히도 Discourse를 이전 버전으로 다운그레이드하는 것은 불가능합니다. 하지만 향후 이를 피하고 싶으시다면 release/2026.7으로 고정하시고(2026.7의 지원이 종료되기 전에 해당 고정 설정을 수동으로 업데이트하는 것을 잊지 마세요) 진행하시길 권장합니다.
3개의 좋아요
감사합니다. 아마도 가장 확실하고 자동화된 방법으로, 여전히 지원되는 가장 오래된 버전, 즉 가장 느린 개발 경로를 유지하는 방법을 찾고 있는 것 같습니다.
4개의 좋아요
저도 마찬가지입니다. 그리고 저는 esr이 (거의) 그렇게 한다고 생각합니다. 몇 개월마다 새로운 esr이 나오고 거기로 이동하게 되는데, 방금 그런 일이 일어났습니다. 하지만 사실 기존 esr은 아직 2개월간의 유지보수 기간이 남아 있어서, 이전 esr에 머물러 있을 것으로 예상됩니다. (그렇게 하고 싶은 것은 합리적인 것 같습니다. esr-maintained 라벨이 필요할까요?)
5개의 좋아요
고려해 볼 만한 합리적인 생각이지만, 이 점도 함께 생각해 보세요… v2026.1이 더 이상 유지보수되지 않게 된 2개월 후에는 상황이 어떻게 달라지겠습니까?
추가적인 변경 사항이 없다면, 그 시점에도 여전히 “예고 없이” 업데이트가 적용될 것입니다.
그것이 괜찮은가요?
2개의 좋아요
네, 저는 여전히 오래된 ESR을 더 오래 유지하려는 것이 합리적이라고 생각합니다. 이렇게 하면 새로운 ESR이 어느 정도 테스트를 거쳤고, 일부 수정 사항이 반영되었을 가능성이 있습니다.
저는 새로운 ESR을 1시간 만에 도입했는데, 약간 후회하고 있습니다. 현재 상황이라면 이전 버전으로 고정하고 보안 업데이트만 받는 것이 최선일 것입니다. 이는 긴급한 보안 수정 사항을 관리적 학습 곡선과 곧 수정될 새로운 버그로부터 분리시킵니다. 매우 도움이 되는
2026.1 ESR에서 2026.7로 전환 - 제가 발견한 것들
(새로 나온 ESR에서 왜 새로운 버그가 발생한다고 기대해야 할까요? 제가 아는 한, 새로운 ESR은 출시 순간까지 연속적으로 개발되었기 때문입니다. 안정화 단계가 없습니다.)
3개의 좋아요
이것이 가장 큰 문제입니다.
즉, esr-maintained를 사용 중이라면 2개월 후 esr과 esr-maintained가 동일한 브랜치가 되는 것이 맞나요? 그렇다면 2개월 후에도 여전히 큰 변화에 대해 놀라게 될 것입니다.
esr과 esr-maintained가 동일한 브랜치가 아니라면, Discourse가 "ESR 유예 기간"에 진입했음을 알리는 경고를 표시할 수 있습니다. 이 경보는 컨테이너를 재빌드할 때가 아니라 포럼에서 관리자만 볼 수 있도록 표시될 수 있습니다.
ESR 롤오버에 대한 사전 통지가 있으면 이 지원되는 유예 기간 동안 업그레이드를 계획하고 테스트할 수 있어 좋습니다.
4개의 좋아요
이상적인 상황에서는, 이 두 달 동안 스테이징 서버를 새 ESR으로 업데이트할 수 있으며, 프로덕션에서는 이 기간을 커버하기 위해 보안 업데이트가 적용된 이전 ESR을 계속 실행할 수 있습니다.
패치된 이전 ESR을 추적하기 위해 간단한 라벨링 시스템을 도입하여, 이전 ESR의 유지보수 업데이트를 자동으로 받도록 하는 것이 실제로 합리적인 방법입니다.
이미 이를 구현할 수 있는 방법이 있을까요?
2개의 좋아요
ESR에 그렇게 많은 버그 수정이 반영될 것 같지는 않습니다. 2026.1과 마찬가지로, 이제부터는 보안 수정만 이루어질 것입니다.
따라서 한 달 후 일부 버그가 알려지더라도, 그 버그를 처리하지 않아도 된다는 의미는 아닙니다.
3개의 좋아요
비관적인 입장을 취하자면, 두고 보겠습니다! 막 출시된 ESR에서 어리석은 호환성 파괴 변경 사항이 발견된다면 수정될 거라고 생각합니다. 아마도 그런 일이 실제로 일어나는 것을 볼 수 있을 만큼 이 새로운 환경이 오래 지속되지 않았기 때문일 것입니다. 실제로는 단순한 불편함 수준의 문제에 대해서는 수정을 기대하지 않습니다.
2개의 좋아요