정말 멋진데요 
지금 3.5.3으로의 안정적 업데이트가 없으며, 이것이 우연한 일치일 수도 있다는 뜻으로 이해하면 맞나요?
네, 우연의 일치입니다. 이번 달에는 보안 수정 사항이 없어서 릴리스할 것이 없었습니다.
Stable 3.5는 여전히 완전히 지원됩니다.
안녕하세요,
이전에는 beta 태그를 사용했는데, 이제 새로운 설정에 맞게 스크립트를 업데이트하려고 합니다. 제가 파악한 바로는 저장소가 다음과 같이 보입니다:
* b541e99ea2 (origin/tests-passed, origin/main, origin/latest) DEV: Exclude new table in IntermediateDB config
* 02dfb651ae DEV: Add support for converting and importing `category_moderation_groups`
.
.
.
* 1dde082e96 UX: update lightbox quote icon to apply shadow (#36247)
* 3e7317b334 (tag: v2025.12.0-latest, tag: release) DEV: Begin development of v2025.12.0-latest (#36249)
| * 48167b94d6 (origin/release/2025.11) Backport limited body overflow (#36256)
| * 75d61b40ee (tag: v2025.11.0) DEV: Bump version on `release/2025.11` to `v2025.11.0` (#36251)
|/
* e3f0320395 FIX: uses overflow hidden body on iOS (#36248)
.
.
.
* 05cd20d401 Bump version to v3.6.0.beta3-latest
* 8a3cb59d5b (tag: v3.6.0.beta2, tag: latest-release, tag: beta) Bump version to v3.6.0.beta2
* 21e5ded097 DEV: remove redundant data attr when cooking posts (#35650)
beta태그가 여전히v3.6.0.beta2를 가리키고 있는 것이 정상인가요?release태그가release/2025.11브랜치의 리비전을 가리키지 않는 것이 정상인가요?
감사합니다 
안녕하세요 @simonk, 그 부분들을 언급해 주셔서 감사합니다! 사실 오늘 내부적으로 두 가지 모두에 대해 논의하고 있습니다.
-
기존
beta와latest-release태그는release의 별칭(aliases)이어야 합니다. -
release는release/2025.11의 최신 커밋을 추적해야 합니다.
지금 바로 수정하고 있습니다.
해당 태그 3개는 이제 수동으로 올바른 커밋으로 이동되었습니다. 향후 자동화 도구가 업데이트되어 태그가 올바른 위치에 유지되도록 하겠습니다.
* commit 48167b94d63faf8a41b9c8193ec5dd3e4e9f498e (HEAD -> release/2025.11, tag: release, tag: latest-release, tag: beta, origin/release/2025.11)
| Author: Joffrey JAFFEUX <j.jaffeux@gmail.com>
| Date: Wed Nov 26 14:31:55 2025 +0100
|
| Backport limited body overflow (#36256)
|
프로덕션 환경에서 발견된 특이사항입니다.
셀프 호스팅한 Discourse에서는 여전히 3.6.0.beta2가 최신 릴리스로 표시되고 있었습니다. 관리자 대시보드에서는 녹색 이모지가 최신 릴리스를 사용 중임을 나타내고 있었지만, 실제로는 두 버전이 뒤처져 있었습니다.
수동 업데이트를 수행하여 현재는 2025.12.0-latest 버전을 사용하고 있습니다.
릴리스 도구에서 3.6.0.beta2를 구버전으로 표시하고 업데이트를 요구하도록 설정할 수 있는 방법이 있을까요?
네, 맞습니다. Stable 3.5에는 git에 자체 브랜치가 없으므로, stable 브랜치를 태그로 변환한 후에도 이를 계속 지원하는 것은 까다롭습니다. stable 브랜치를 삭제하기 직전에 v3.5.4(최신 보안 패치를 포함)를 태그했으므로, 2026.1로 전환하기 전에 조금 더 시간이 필요하다면 해당 버전을 사용하는 것이 괜찮습니다. 하지만 3.5 시리즈에 대한 향후 보안 패치는 제공되지 않습니다.
2026.7 ESR을 출시하면, 릴리스 브랜치에서 2026.1을 2개월 동안 계속 지원하게 됩니다.
확인해 보겠습니다. 감사합니다.
이 구체적인 구성 예제가 어떤 모습인지 알고 싶습니다.
env:
DISCOURSE_VERSION: bd4e34ec04
아니면
version: bd4e34ec04
기억이 맞다면 version을 stable로 설정할 수 있습니다.
네, 방금 templates/web.template.yml에서 설정할 수 있다는 걸 찾았습니다.
params:
version: esr
음… 그러면 Understanding Discourse release channels 도 수정해야 하나요?
이 게시물의 내용은 이제 구식이 된 것 같습니다. 현재 안정판은 esr 태그만 있으면 충분할 것입니다. 또는 최신 기능을 사용하려면 latest 태그를 사용하시면 됩니다.
그렇게 생각합니다. David가 이전에 문서화에 대해 언급한 적이 있습니다.
새 시스템에 대해 여전히 약간 혼란스럽습니다 - app.yml 파일을 전혀 변경하지 않았거든요.
그리고 각 새 릴리스에 대한 공지 스레드가 그리워집니다.
그냥 그렇게 된 것 같네요 
!
ESR 버전으로 보안 업데이트를 백포트하는 데 관한 프로토콜은 무엇입니까? 특히, 의존성 버전 업데이트에 대해 궁금합니다. 현재 저희 사이트는 v2026.1.3을 실행 중이며, 곧 v2026.7.2로 업그레이드될 예정입니다. 보안 스캔과 플래깅된 취약점을 살펴보고, CVE를 해결하는 월간 릴리스의 패키지 업데이트와 대조해 본 결과, ESR 버전에는 반영되지 않는 업데이트들이 있는 것을 발견했습니다.