버전 번호 체계 및 릴리스 프로세스를 전면 개편하기 위한 진행 중인 프로젝트의 일환으로, releases.discourse.org의 출시를 기쁘게 알립니다.
앞으로 이 사이트는 Discourse 버전, 릴리스 날짜, 지원 타임라인 및 변경 사항에 대한 주요 정보원이 될 것입니다.
홈페이지에서는 최근 버전들과它们的 개발/지원 기간을 시각화한 내용을 확인할 수 있습니다. 특정 버전의 변경 사항을 보려면 클릭하여 이동할 수 있습니다. 예를 들어, 최근 출시된 2025.12.0 릴리스:
향후 릴리스의 경우, Meta에 전용 release-notes 토픽을 작성하는 대신 이 페이지들로 링크를 걸 예정입니다.
이 사이트에는 특정 버전/커밋 범위에 대한 사용자 지정 변경 사항 생성 지원 기능도 포함되어 있습니다. Discourse 자체의 업그레이드 UI에서 이러한 변경 사항으로 링크를 걸기 시작할 계획입니다.
피드백이 있으시면 알려주세요!
releases.discourse.org의 #release-notes에 현재 포함된 플러그인 커밋을 어디서 찾을 수 있나요?
작은 기능 요청입니다:
“상세 변경 사항” 아래에 나열된 개별 변경 사항(commit-card)에 앵커 링크를 추가해 주실 수 있을까요?
특정 변경 사항을 공유하는 것이 훨씬 쉬워질 것입니다 : )
코어 플러그인의 변경 사항은 다른 코어 변경 사항과 함께 포함되므로, 누락된 것은 "비코어 공식 플러그인"뿐입니다. 다른 저장소의 변경 사항을 추가하는 것은 미래에 고려할 수 있지만, 당장 이를 구현할 계획은 없습니다.
비코어 플러그인(공식 및 제3자 모두)의 경우, 현재로서는 변경 사항을 추적하는 가장 좋은 방법은 GitHub일 것입니다.
좋은 아이디어입니다! 커밋 목록이 화면에 보이는 요소만 실제로 렌더링되는 "가상 목록"으로 구현되어 있어 구현이 다소 까다로울 수 있지만, 해볼 수 있는 방법을 찾아보겠습니다.
실망스럽네요. discourse/discourse 저장소에 없는 플러그인들의 요약이 릴리스 노트에서 가장 흥미로웠거든요. 코어 변경 사항은 GitHub에서 한 곳에서 모두 찾을 수 있습니다. 하지만 다른 플러그인들의 변경 사항은 서로 다른 저장소에서 이루어지므로, 이를 쉽게 한 곳에서 추적할 수 있는 곳이 없어요.
활발한 개발과 지원 상태를 시각화하는 좋은 방법인 것 같습니다.
한 가지 눈치챈 점은 v2026.01 릴리스에 [latest] 태그가 붙어 있지만, v3.5처럼 [ESR] 태그도 함께 붙어 있지 않다는 것입니다. 두 태그가 모두 있으면 한눈에 확인하기 유용할 것입니다.
릴리스와 활성 개발 버전 사이에 추가 정보가 제공되고 있는 상황에서, Discourse를 특정 릴리스나 ESR 버전에 고정해 두는 설정(또는 추가 계획)이 있을까요?
이와 관련하여 주목해야 할 또 다른 점은, RFC에서 Discourse의 서로 다른 버전과 호환되는 브랜치를 생성하기 위한 플러그인과 테마 자동화 기능을 구축할 계획이 있다는 것입니다.
이 기능이 자리를 잡은 후에 이 주제로 돌아오는 것이 적절할 것 같습니다.
현재는 배포 설정에서 추적할 브랜치를 설정하여 이를 수행할 수 있습니다:
그러나 이렇게 하면 해당 릴리스에 영원히 고정되는 것과 같습니다. 아직 구축해야 할 부분은, 사용자가 따르는 릴리스 채널에서 새로운 릴리스가 사용 가능해진 시점을 더 잘 확인할 수 있는 방법입니다.
이것이 어떻게 작동할지에 대해 초기 논의를 해왔지만, 세부 사항에 대해서는 아직 논의 중입니다.
정말 훌륭해요. 어떤 버전을 사용하고 있는지, 언제 다음 버전으로의 이동을 계획해야 하는지 한눈에 빠르게 확인할 수 있어서 정말 도움이 됩니다! 이 페이지를 정말 좋아해요 
보안 수정 사항과 주요 기능이 강조되어 있다는 점이 특히 마음에 들어요. 호환성이 깨지는 변경 사항(breaking changes)도 비슷하게 강조되기를 희망합니다.
또한, ESR(장기 지원 릴리스)의 지원 기간을 좀 더 연장해 주면 좋겠다고 제안합니다(예를 들어 1~2개월 정도). 이렇게 하면 두 ESR 모두 비개발 상태(non-active development)이지만 지원 기간 내일 때, 사용자가 한 ESR에서 다른 ESR로 전환할 수 있습니다. 그렇지 않으면 커뮤니티는 잠시 지원이 종료되는 상태로 기다리거나, 일찍 전환해서 지원은 받지만 개발 중(in-dev) 업데이트를 더 많이 받아야 하는 둘 중 하나를 선택해야 합니다. 작은 겹침(overlap)이 있으면 브랜치가 더 안정적으로 정착할 기회가 생깁니다. ESR 수명 주기에 있어서는 꽤 일반적인 방식인데, 미디어위키(Mediawiki)의 경우를 예로 들 수 있습니다:
이것은 특별히 복잡한 것이 아니라, 구버전 ESR 브랜치에 대해 1~2개월 정도 추가적으로 높은 우선순위의 보안 수정 사항만 제공하면 됩니다.
어쨌든 감사합니다. 많은 부분을 명확히 이해하는 데 정말 도움이 됩니다 ^.^
네, 새로운 릴리스 시스템에서는 ESR 지원 기간에 2개월의 겹침(overlap)을 두도록 계획하고 있습니다. 따라서 2026.1은 2026.7 ESR이 릴리스된 후 2개월인 9월까지 지원됩니다.
불행히도 기존 “stable” 3.5의 경우 전용 브랜치가 없어 이러한 겹침을 제공하기가 쉽지 않습니다. 하지만 2026.1부터는 업데이트 주기를 길게 유지하려는 사용자들의 상황이 훨씬 좋아질 것입니다.
정말 좋네요, 감사합니다!
