# RFC: Discourse를 위한 새로운 버전 관리 전략
**URL:** https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536
**Category:** Development
**Tags:** dev-news
**Created:** [9월 23, 2025, 7:55오전 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536 "2025-09-23T07:55:33Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@schneeland](https://meta.discourse.org/u/schneeland)
#### Post date: [9월 24, 2025, 10:58오후 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/22 "2025-09-24T22:58:51Z")
> [@RGJ](#):
>
> 테마/플러그인 개발자가 수정을 적용하는 시점이 문제가 아니라, Discourse 코어에 보안 수정이 적용되는 시점이 문제입니다.
네, 하지만 그렇게 하면 오히려 문제가 더 잘 이해되지 않는 것 같습니다 😕
결국 @david의 최신 코멘트에서 언급했듯이 크게 중요하지 않으므로, 여기서 마무리하겠습니다.
제안된 모델은 월간 릴리스와 ESR 버전 2개입니다. 예를 들어 2026년의 경우:
- 2026.1
- **2026.2**
- 2026.3
- …
- **2026.8**
- _2026.9_
- _2026.10_
- …
즉, 2026년 10월에 있고 .2와 .8이 ESR 버전이라고 가정하면, 지원되는 버전은 4개라는 뜻입니다.
제 생각은 이랬습니다. 기본적으로 분기별 버전을 적용하면, 즉 2026년의 경우:
- 2026.1
- **2026.2**
- **2026.3**
- …
이렇게 하면 현재 버전과 이전 릴리스만 지원되는 구조로 유지할 수 있습니다. 그러면 2026년 10월에는 2.0이 지원되는 버전이 됩니다.
그리고 이 논리의 핵심은 개발자와 사용자 모두에게 더 편해질 수 있지 않을까 하는 것이었습니다. 하지만 위에서 언급했듯이: @david는 덜 잦은 릴리스는 옵션이 아니라고 명확히 했습니다.
---
### Author:  [@schneeland](https://meta.discourse.org/u/schneeland)
#### Post date: [9월 24, 2025, 11:17오후 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/23 "2025-09-24T23:17:43Z")
> [@david](#):
>
> 현재 런처 툴링과 이 새로운 브랜치 구조를 사용하면 다음과 같은 방식으로 업그레이드 시점을 제어할 수 있습니다:
>
> …
>
> 하지만 매월 `app.yml` 파일을 수동으로 편집하는 것은 이상적이지 않으므로, 이 과정을 더 사용자 친화적으로 만들 수 있는 시스템을 설계할 수 있기를 바랍니다.
알겠습니다. 제가 예상했던 방식과 거의 일치합니다. 실제로 이 경우, 적어도 중기적으로 일부 도구 지원이 있으면 좋겠습니다.
제가 이 개념을 이해하는 방식은 다음과 같습니다: 사용자는 특정 릴리스 채널(최신, 릴리스, ESR)에 있으며, 일반적으로는 다음 릴리스로 비교적 빠르게 전환하게 됩니다. 따라서 새 릴리스가 사용 가능하다는 메시지/알림을 받고, 이를 전환하기 위한 단일 명령을 사용할 수 있으면 좋겠습니다. 또한 새 릴리스 도입을 지연시킨 경우, 현재 사용 중인 릴리스가 더 이상 지원되지 않거나 구식이 되었을 때 알림을 받을 수 있으면 좋겠습니다. 해당 도구가 릴리스 채널도 빠르게 전환할 수 있게 해준다면 더 좋겠습니다. 🙂
하지만 현재 이것이 최우선 순위가 아니라는 점, 그리고 여전히 테스트를 통과한 최신 버전(test-passed/latest)을 유지할 것을 권장한다는 점은 이해합니다.
> [@david](#):
>
> 우리는 Discourse 개발의 속도와 광범위한 커스터마이징을 가진 사용자들의 안정성 사이의 균형을 맞추려 하고 있습니다. 고객에게 기능이 전달되는 데 3개월 이상의 지연은 옵션이 아닙니다. 오히려 월간 주기는 우리에게 느린 편입니다.
알겠습니다. 제 업무 맥락에서는 고객에게 기능을 배포하는 것이 "빠르다"고 여겨집니다. 😅
또한 위에서 언급했듯이, 분기별 일정으로 전환하면 유지보수해야 할 브랜치가 줄어들어 여러분의 삶(그리고 플러그인/테마 개발자의 삶)이 더 쉬워질 것이라고 생각했습니다. 만약 그렇지 않다면, 당신들에게는 정말로 의미가 없는 것 같습니다. 🙂
---
### Author:  [@per1234](https://meta.discourse.org/u/per1234)
#### Post date: [9월 26, 2025, 4:06오후 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/24 "2025-09-26T16:06:36Z")
제안하신 연도 기반 버전 관리 방식에는 아무런 이점이 보이지 않습니다. [SemVer](https://semver.org/)에 부합하는 버전 번호를 유지하세요!
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [9월 26, 2025, 4:16오후 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/25 "2025-09-26T16:16:03Z")
SemVer 자체는 대규모 애플리케이션을 위해 특별히 설계된 것이 아닙니다. 소프트웨어에서 소비되는 라이브러리를 더 많이 대상으로 한다고 이해하고 있으며, 특히 버전 번호 체계는 패키지의 API를 중심으로 구축되어 있습니다.
다만, 우리는 SemVer를 API에 적용할 수는 있습니다. Discourse가 노출하는 API에 대해 더 강력한 보장을 갖는 것은 분명히 가치가 있는 논의이지만, 이는 이번 주제와 별개라고 생각합니다.
이제, SemVer에 준수해야 한다고 말씀하신 것이 아니라, SemVer에서 지정된 번호 체계에 부합하는 \_숫자\_를 계속 사용해야 한다고만 말씀하신 것임을 이해합니다.
> 1. 일반적인 버전 번호는 X.Y.Z 형식을 가져야 하며, 여기서 X, Y, Z는 음이 아닌 정수여야 하고, 앞선 영숫자(leading zeroes)를 포함해서는 안 됩니다. X는 메이저 버전, Y는 마이너 버전, Z는 패치 버전을 나타냅니다. 각 요소는 수치적으로 증가해야 합니다. 예를 들어: 1.9.0 → 1.10.0 → 1.11.0.
저는 우리가 그 방향으로 간다면, "앞선 영숫자"에 대한 제안이 우리가 벗어나게 될 유일한 부분이라고 생각합니다.
그 외에는, 우리가 제안하는 버전 번호를 어떤 SemVer 라이브러리도 여전히 올바르게 파싱하고 정렬할 수 있을 것이라고 생각합니다.
이 모든 것을 제쳐두고, SemVer 번호 체계에 준수하는 것이 왜 가치가 있다고 생각하시는지 더 자세히 공유해 주시겠습니까?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [9월 26, 2025, 7:11오후 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/26 "2025-09-26T19:11:15Z")
> [@mcwumbly](#):
>
> 저 경로로 간다면 우리가 기존 관행에서 벗어나게 되는 부분은 “선도 영(leading zeroes)” 제안일 것 같습니다.
제가 이해한 바로는, OP(질문자)는 선도 영을 사용하지 않는다고 말씀하신 것 같습니다.
> [@david](#):
>
> 예를 들어 2026년의 첫 릴리스는 `v2026.0`, 그 다음은 `v2026.1` 등으로 하는 식입니다.
버전 정렬을 위해 선도 영을 사용하는 것이 설득력 있는 이유라는 제안도 있었습니다. 현재 계획에 선도 영이 포함되나요? (여전히 연속 번호 기반 버전보다 월 단위 버전을 선호합니다).
---
### Author:  [@per1234](https://meta.discourse.org/u/per1234)
#### Post date: [9월 26, 2025, 9:06오후 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/27 "2025-09-26T21:06:20Z")
SemVer의 핵심은 버전 번호가 유용한 정보를 전달해야 한다는 것입니다. 귀하가 제안한 방식에서 전달되는 유일한 정보는 지구가 태양을 도는 궤도뿐입니다. 이는 소프트웨어 사용자에게 매우 유용하지 않은 정보입니다.
만약 어떤 이유로 출시 날짜를 알고 싶다면, 출시 기록을 확인하여 정확한 날짜를 얻으면 됩니다.
> [@mcwumbly](#):
>
> SemVer 자체는 대규모 애플리케이션을 위해 설계된 것이 아닙니다. 소프트웨어에 의해 소비되는 라이브러리를 더 많이 대상으로 한다고 이해하고 있으며, 특히 버전 번호링 로직은 패키지의 API를 중심으로 구축되어 있습니다.
그렇지 않습니다. 핵심은 릴리스의 성격을 사용자에게 전달하는 것입니다.
릴리스가 패치 버전 증가(patch version bump)인 경우, 이는 변경 사항에 소프트웨어 사용자의 워크플로우에 영향을 미칠 것으로 예상되는 내용이 포함되어 있지 않음을 전달하는 것입니다.
릴리스가 마이너 버전 증가(minor version bump)인 경우, 이는 변경 사항에 사용자 대상 새로운 컴포넌트가 추가되었지만, 소프트웨어 사용자의 기존 워크플로우를 깨뜨리는 내용은 포함되지 않음을 전달하는 것입니다.
릴리스가 메이저 버전 증가(major version bump)인 경우, 이는 변경 사항에 소프트웨어 사용자의 기존 워크플로우를 깨뜨릴 수 있는 변경 사항이 포함되었음을 전달하는 것입니다.
어떤 버전 컴포넌트를 증가시킬지 결정하는 것은 단일 사용자 인터페이스를 가진 소프트웨어 제품에서 더 명확하지만, Discourse와 같이 다양한 수준의 인터페이스와 유형의 소비자(예: 플러그인 개발자, API 소비자, 포럼 스태프, 최종 사용자)가 있는 소프트웨어 제품에서도 원칙은 동일하게 유지됩니다.
이 소프트웨어 프로젝트에서 어떤 컴포넌트를 증가시킬지 선택하는 것이 다소 주관적일 수 있지만, 여전히 귀하의 제안처럼 단순히 임의의 숫자가 아니라 버전 번호에 의미가 부여됩니다.
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [9월 26, 2025, 9:57오후 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/28 "2025-09-26T21:57:02Z")
> [@pfaffman](#):
>
> 제대로 이해했으면, OP는 선두에 0을 사용하지 않는다고 말하고 있습니다.
저는 몇 포스트 전에 그걸 제안했습니다.
> [@per1234](#):
>
> 버전 번호가 단순히 아무 숫자가 아니라 의미를 가진 것, 이는 당신의 제안의 경우입니다.
semver와 달리, 제안된 버전 번호 체계는 해당 버전이 여전히 지원되는지(예: Ubuntu)를 즉시 명확하게 보여줍니다. 이는 지구의 태양 공전에도 의존하므로, 실제로는 의미가 있습니다.
> [@per1234](#):
>
> 릴리스가 메이저 버전 업데이트인 경우, 이는 소프트웨어 사용자의 기존 워크플로를 깨뜨릴 수 있는 변경 사항이 포함되었음을 알리는 것입니다.
이것은 명확하게 패키지나 라이브러리를 대상으로 하고 있습니다. _모든_ Discourse 릴리스에는 소프트웨어 사용자의 기존 워크플로를 깨뜨릴 수 있는 변경 사항이 포함됩니다. 심지어 보안 패치에서도 그런 일이 있었던 것을 본 적 있습니다. Semver은 복잡한 애플리케이션에 사용할 수 없습니다.
> [@per1234](#):
>
> > [@mcwumbly](#):
> >
> > 버전 번호화 논리는 패키지의 API를 중심으로 구축되어 있습니다.
>
> 그렇지 않습니다. 핵심은 릴리스의 성격을 사용자에게 전달하는 것입니다.
정말 그렇습니다. [참고](https://semver.org/)
> 공개 API를 식별한 후에는 버전 번호의 특정 증분을 통해 API 변경 사항을 전달합니다.
---
### Author:  [@nickrsan](https://meta.discourse.org/u/nickrsan)
#### Post date: [9월 26, 2025, 10:03오후 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/29 "2025-09-26T22:03:40Z")
> [@Ed\_S](#):
>
> 가장 부드럽게 수행하는 방법에 대한 좋은 설명이 있습니다.
누락될 수 있는 점을 강조하고 싶습니다. 저는 Discourse가 이 부분에서 잘하고 있다고 생각합니다. 한 가지 개선 사항은 해당 업그레이드 사이클 내에서 변경 사항과 잠재적인 깨짐(breakage)을 설명하는 이미 작성된 주제들을 최소한 하이라이트하는 것입니다. 예를 들어, 3.5 릴리스의 경우 릴리스 노트를 열고 블로그로 이동한 후, Discourse 코어에 플러그인을 번들링하는 것에 대한 링크를 우연히 클릭해야만, 설정 파일에 해당 플러그인을 남겨두면 업그레이드에 영향을 미칠 수 있다는 세부 사항을 알아낼 수 있었습니다.
ESR 릴리스의 경우, ESR 업그레이드를 수행하기 전에 검토해야 하는 기존 주제에 대한 링크 모음이더라도, 이러한 유형의 노트를 페이지/주제로 분리해 내는 것이 좋을 것입니다.
이것은 이 스레드의 범위를 벗어날 수 있지만, 버전 관리 변경 사항에 대한 제 피드백은 이를 환영하며 여기의 투명성을 높이 평가한다는 것입니다. 저는 이것이 더 많은 셀프호스팅 옵션을 제공하면서 일을 단순화하는 훌륭한 개선이 될 것이라고 생각합니다.
감사합니다!
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [9월 26, 2025, 10:10오후 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/30 "2025-09-26T22:10:57Z")
> [@RGJ](#):
>
> 아까 몇 개 위에 그걸 제안했잖아요.
네, 정말 좋은 아이디어라 OP(게시물)에도 반영하도록 수정해야 한다고 생각해요!
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [9월 26, 2025, 10:16오후 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/31 "2025-09-26T22:16:40Z")
선두의 영과 월과 더 명시적으로 동기화를 맞출지 여부는 현재 검토 중입니다. 이 작업을 진행하는 그룹이 결정을 내리면 @david가 업데이트를 공유할 예정입니다.
---
### Author:  [@per1234](https://meta.discourse.org/u/per1234)
#### Post date: [9월 26, 2025, 10:55오후 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/32 "2025-09-26T22:55:17Z")
> [@RGJ](#):
>
> 제안된 버전 번호 체계는 해당 버전이 여전히 지원되는지 즉시 명확하게 보여줍니다.
새 릴리스를 평가하는 포럼 관리자에게 중요한 정보는 아닙니다.
> [@RGJ](#):
>
> 네, 정말로요.
아니요, 정말입니다. "API"가 실제로는 인터페이스를 의미한다는 점을 이해하기를 거부함으로써 SemVer의 실제 요점을 놓치고 있습니다. SemVer의 정신을 모든 유형의 소프트웨어 버전 관리에 적용할 수 없는 이유는 전혀 없습니다.
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [9월 27, 2025, 12:42오전 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/33 "2025-09-27T00:42:13Z")
이 문제에 대해서는 의견이 다를 수밖에 없을 것 같습니다 @per1234.
semver의 GitHub 저장소에서 [관련 논의](https://github.com/semver/semver/issues/971#issuecomment-1714578322)와 [유지보수자 중 한 명](https://github.com/semver/semver/blob/master/CONTRIBUTING.md#the-semver-team)의 답변을 공유합니다:
> Semver은 "최종 사용자 앱"에는 실제로 유용하지 않으며, 프로젝트의 종속성으로 사용되는 라이브러리에는 더 유용합니다.
---
### Author:  [@elmuerte](https://meta.discourse.org/u/elmuerte)
#### Post date: [9월 27, 2025, 6:35오전 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/34 "2025-09-27T06:35:38Z")
라이브러리든 더 큰 애플리케이션이든 사실 큰 차이는 없습니다. 시맨틱 버전 관리(such as semver) 방식은 대형 애플리케이션에도 완벽하게 잘 작동합니다. 플랫폼으로 번들링된 애플리케이션 모음에도 사용할 수 있지만, 이 경우 적용하기가 꽤 어려워집니다.
주된 질문은 특정 릴리스에서 지원되는 비추천(deprecation) 기능을 도입하고, 다음 메이저 버전에서만 이를 제거하는 경로를 선택하는 것이냐는 것입니다. 비추천되었지만 여전히 지원되는 기능을 유지하는 것은 상당한 노력이 필요합니다. 영속 데이터 모델(persisted data model)을 변경할 때는 비추천 처리가 아예 불가능한 경우가 많습니다. 그런 일이 발생하면 비추천 기능이 포함된 마이너 버전 릴리스조차 할 수 없으며, 즉시 다음 메이저 버전으로 넘어가야 합니다. 대형 애플리케이션이 보통 문제를 겪는 부분이 바로 여기입니다. 후방 호환성을 제공할 수 없어 3.0.0에서 3.0.1을 거쳐 4.0.0으로 건너뛰게 됩니다. 깨지는 변경(breaking changes)이 잦다면 semver을 고수하는 것이 거의 가치를 주지 못합니다.
그럼에도 불구하고, 저는 이 구성을 훨씬 더 선호합니다. 개발자에게 깨지는 변경이 있을 것이라는 점을 더 명확하게 전달할 수 있기 때문입니다. YYYY.N 방식은 개발자로서도, 관리자로서도 아무런 정보를 주지 못합니다.
그러면 질문은, 버전으로 무엇을 전달하고 싶은가에 달려 있습니다. 6개의 기능 릴리스(깨지는 변경이 있을 수도, 없을 수도 있음)를 수행하고, 6번째 릴리스마다 패치를 통해 더 긴 기간 동안 지원하며, 패치 릴리스에는 버전을 매기지 않으려면 X.Y 방식이 적합합니다. 여기서 Y=0이 더 긴 기간 동안 지원되는 버전입니다. X는 단순히 숫자입니다. 문제는 X가 연도일 경우, Y가 빠르게 월과 연관 지어지다는 것입니다. 그러면 더 긴 기간 동안 지원되는 새로운 릴리스가 항상 1월에 출시되는 걸까요? 저는 항상 어떤 Ubuntu 버전이 LTS인지 찾아봐야 해서 번거롭습니다.
그렇다면 Discourse가 단순히 현재 메이저 버전을 계속 이어가는 것은 어떨까요. 다음 장기 지원(LTS) 버전은 4.0이라고 부르고, 그 후 4.1부터 4.5까지 기능 릴리스를 진행하며, 그 다음에는 최신 장기 지원 버전인 5.0이 나온다고 가정해 보겠습니다.
이렇게 하면 메이저 이슈로 인해 릴리스가 지연되는 그 어색한 순간도 사라집니다.
롤링 패치 릴리스를 하는 대신 명시적으로 패치를 릴리스할 계획이 있다면 선택적으로 “패치” 번호를 추가할 수 있습니다. "그럼 x.y.z인데, 이건 semver 아냐?"라고 할 수 있지만, 아닙니다. semver처럼 보일 뿐, 실제로는 아닙니다. 모든 새로운 “마이너” 릴리스가 깨지는 변경을 포함할 수 있기 때문입니다. 그래서 저는 Y=0 → LTS인 X.Y 버전 방식을 유지할 것을 제안합니다.
버전 문자열 문제는 일단 제쳐두겠습니다. 저는 새로운 릴리스 계획 자체는 마음에 듭니다.
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [9월 27, 2025, 12:22오후 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/35 "2025-09-27T12:22:32Z")
> [@elmuerte](#):
>
> 빈번하게 깨지는 변경 사항(breaking changes)이 발생한다면, 세마버(semver)를 고수하는 것은 거의 가치를 더해 주지 않습니다.
네, 특히 유연한 테마 시스템의 경우 현재 상황은 사실상 그렇습니다.
그래서 저는 여기에서 말씀하신 부분이 정확하다고 생각합니다:
> [@elmuerte](#):
>
> “하지만 그러면 x.y.z 형식이 되어 세마버가 되는 거 아냐?”. 아니요, 세마버처럼 보일 뿐 실제로는 그렇지 않습니다. 모든 새로운 “마이너” 릴리스가 깨지는 변경 사항을 포함할 수 있습니다.
또한, 현재 버전 번호의 “메이저(major)” 부분이 거의 아무것도 전달하지 못한다는 의미이기도 합니다.
그래서 '자, 아무것도 전달하기보다는 연도를 사용해 \_무언가\_를 전달하는 게 낫겠군’이라고 생각했습니다.
> [@elmuerte](#):
>
> 버전 문자열은 차치하고, 새로운 릴리스 계획은 마음에 듭니다.
🚀
---
### Author:  [@hellekin](https://meta.discourse.org/u/hellekin)
#### Post date: [9월 30, 2025, 12:57오전 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/36 "2025-09-30T00:57:40Z")
이 토론은 좋은 방향으로 보이지 않습니다. 개발 팀이 자신들에게 적합한 새로운 버전 관리 체계를 수용하기로 결정한 것처럼 보이지만, 다른 쪽에서는 갑자기 Discourse 버전이 시맨틱 버전 관리(Semantic Versioning)를 따랐던 것처럼 주장하고 있습니다… 하지만 실제로는 그렇지 않았습니다. 적어도 1.0 버전부터는 롤링 릴리스(Rolling Release) 방식이었죠, 맞나요?
하지만 토론 양측의 논거들은 모두 결함이 있어 보입니다:
- “산업 표준”: Linux는 안정 버전(even major)과 개발 버전(odd major)을 구분하여 사용합니다.
- “지구 공전”: 음, 이슬람교로 개종하면 문제가 생길 텐데, 버전을 건너뛰게 되면 더 이상 태양의 공전 주기와 맞지 않고 달의 주기와 맞게 됩니다. 여기서 이제 X.Y.Z 대신 YYYY.Y.Z 버전 관리 방식을 선택함으로써 지배적인 문화를 강요했다는 것을 이해하게 됩니다.
- 마이너 릴리스는 여전히 불분명합니다: "월별 주기를 가정한다"고 언급하셨지만, 기능에 따라 3주나 7주도 될 수 있습니다. 이 경우 Y를 0부터 세는 것이 의미가 있을 수 있거나, 실제로 월별 릴리스를 목표로 하고 있다면 M을 1부터 세는 것이 더 의미가 있을 것입니다.
제가 보는 주요 변화는 월별 주기를 채택함으로써 Discourse 팀이 기대치를 설정하고, 릴리스 목표에서 벗어나 정기적인 릴리스를 수용하고 있다는 점입니다.
8개월의 LTS는 정말로 "장기적"이라고 느껴지지 않습니다. NodeJS는 너무 빠르게 움직이지만, 30개월 이상 LTS 지원을 유지하고 동시에 몇 가지 최신 버전을 유지합니다. 반면 Ubuntu는 수년간 LTS를 유지합니다. Discourse가 언어나 운영체제가 아니라는 점은 이해하지만, 새로운 기능이 상당히 빠른 속도로 출시될 것이라고 암시하는 것 같아 또 다른 문제가 떠오릅니다. 이제부터 때때로 새로운 관리자 설정이 도입되므로, 곧 무한한 옵션과 사이트 관리에 대한 이해할 수 없는 복잡성, 즉 볼트웨어(Bloatware)의 Wordpress 지옥에 빠질 것입니다. 따라서 목표가 있는 기존 릴리스에서 정기적인 릴리스로 전환하는 방법, 그리고 어떤 목표를 릴리스에서 제외(또는 연기)할지 선택하는지 등을 명확히 하는 것이 중요해집니다. (이미 문서화되어 있을 수 있지만, 제가 그 부분을 놓쳤을 수도 있습니다.)
개발/버전 관리의 속도 사이에서你们的 논거를 공유해 주시겠습니까? 그리고 관리자들이 너무 많은 설정과 높아진 학습 곡선 아래에서 허덕이지 않도록 어떤 방안을 가지고 계신지 궁금합니다.
❤ :discourse:
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [9월 30, 2025, 1:34오전 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/37 "2025-09-30T01:34:56Z")
다른 질문들에 답하기 전에, 이 제안으로 인해 우리가 의도하는 릴리스 주기가 변하지 않는다는 점을 먼저 명확히 하고 싶습니다.
- 지난 3년간 우리는 대략 6개월마다 “안정판(stable)” 릴리스를 수행해 왔으며, 1월과 7월 말을 목표로 삼되 여기저기서 일부 지연이 발생했습니다:
- [3.0.0](https://meta.discourse.org/t/3-0-0-major-release/249002/1): 2023년 1월
- [3.1.0](https://meta.discourse.org/t/3-1-0-major-release/273447/1): 2023년 8월
- [3.2.0](https://meta.discourse.org/t/3-2-0-major-release/293493/1): 2024년 1월
- [3.3.0](https://meta.discourse.org/t/3-3-0-major-release/316353/1): 2024년 7월
- [3.4.0](https://meta.discourse.org/t/3-4-0-major-release/349303/1): 2025년 2월
- [3.5.0](https://meta.discourse.org/t/3-5-0-major-release/379212): 2025년 8월
- 지난 약 8개월간, 몇 가지 대외 보안 릴리스를 제외하고 대략 매달 “베타” 릴리스를 수행해 왔습니다:
- [3.5.0-beta1](https://meta.discourse.org/t/3-5-0-beta1-dark-light-mode-selector-better-flagging-info-and-encouraging-more-valuable-conversations/353246/1): 2025년 2월 24일
- [3.5.0-beta2](https://meta.discourse.org/t/3-5-0-beta2-review-queue-welcome-banner-admin-interface-and-more/358151/1): 2025년 3월 25일
- [3.5.0-beta3](https://meta.discourse.org/t/3-5-0beta3-full-admin-search-better-font-selection-more-robust-site-search-category-personalization-and-easier-configuration-management/362894/1): 2025년 4월 29일
- [3.5.0-beta4](https://meta.discourse.org/t/3-5-0-beta4-security-fix-release/364850/1) 2025년 5월 5일 (대외 보안 릴리스)
- [3.5.0-beta5](https://meta.discourse.org/t/3-5-0-beta5-improved-admin-search-ai-forum-research-easier-site-appearance-configuration-and-simpler-plugin-development/367300/1): 2025년 5월 28일
- [3.5.0-beta6](https://meta.discourse.org/t/3-5-0-beta6-security-fixes-release/369346) (대외 보안 릴리스)
- [3.5.0-beta7](https://meta.discourse.org/t/3-5-0-beta7-smart-link-editing-better-invite-tracking-unique-icons-and-fixing-name-management/370633/1): 2025년 6월 24일
- [3.5.0-beta8](https://meta.discourse.org/t/3-5-0-beta8-bundled-plugins-a-new-theme-better-color-management-powerful-filtering-and-advanced-image-controls/375746): 2025년 7월 28일
이 새로운 제안에서는 우리가 지금까지 따르고 있는 동일한 주기를 유지할 계획이며, 주요 변경 사항은 다음과 같습니다:
- 현재 "안정판"이라고 부르는 릴리스를 "확장 지원 릴리스"라고 부를 것입니다.
- 우리는 장기 지원(LTS)이 아니라 _확장_ 지원이라는 이름을 선택했습니다. 이는 우리의 다른 지원 대상 릴리스에 비해 \_확장\_된 기간이지만 반드시 "장기"는 아니기 때문입니다. 이 제안에는 장기 지원 릴리스 추가가 포함되지 않습니다.
- 현재, 안정판 릴리스에 대한 지원은 다음 릴리스가 출시되는 즉시 \_종료\_됩니다. 이 새로운 제안에 따르면, 보안 패치를 받으면서 업그레이드를 할 시간을 가질 수 있도록 지원 기간이 약 2개월간 겹치게 됩니다.
- 현재 "베타"라고 부르는 릴리스를 "릴리스"라고 부를 것입니다.
- 현재 우리는 베타 릴리스에 대해 출시일 이후로 전혀 지원을 제공하지 않습니다. 이들은 보안 수정도 종종 포함되며, 빠른 전환을 알리는 통보와 함께 제공되는 단순한 중간 지점에 불과합니다.
- 이 제안에 따라 우리는 약 2개월 동안 릴리스에 대한 지원을 제공할 계획이며, 사용자는 보안 패치를 계속 받으면서 업그레이드 시점을 결정할 수 있습니다.
이 점을 고려할 때, 설정이 너무 많다는 다른 질문들은 이 제안과 여전히 관련이 있다고 생각하시나요? 아니면 별도의 주제에서 논의하는 것이 더 나은 독립적인 우려 사항인가요?
---
### Author:  [@hellekin](https://meta.discourse.org/u/hellekin)
#### Post date: [9월 30, 2025, 10:27오전 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/38 "2025-09-30T10:27:28Z")
@mcwumbly 님, 자세한 설명 감사합니다!
> [@mcwumbly](#):
>
> 그 점을 고려할 때, 설정이 너무 많다는 다른 질문들도 이 제안과 여전히 관련이 있다고 보시나요? 아니면 별도의 주제에서 논의하는 것이 더 나은 독립적인 우려 사항인가요?
실제로 이것은 별개의 문제입니다. 플러그인을 통해 관리자 화면을 커스터마이징할 수 있다면, 최종 형태가 어떻게 될지 테스트하는 데 유용할 것입니다. 이러한 접근 방식에 대한 진행 중인 작업이 있나요?
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [10월 1, 2025, 2:10오전 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/39 "2025-10-01T02:10:42Z")
> [@hellekin](#):
>
> 플러그인을 사용해 관리자 화면을 커스터마이징할 수 있다면, 최종 결과물이 어떤 모습일지 테스트하는 데 유용할 것 같습니다. 이러한 접근 방식에 대해 현재 진행 중인 작업이 있나요?
특히 그 부분은 아니지만, 지난 1년간 관리자 UI 개선에 상당한 투자를 해왔습니다. 이러한 주제에 대해 더 깊이 논의하고 싶으시다면, 새 주제를 개설해 논의하고 싶은 문제점이나 아이디어를 구체적으로 정리해 주시겠어요?
---
### Author:  [@SkyeDragon](https://meta.discourse.org/u/SkyeDragon)
#### Post date: [10월 3, 2025, 1:47오전 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/40 "2025-10-03T01:47:10Z")
훌륭한 변경 사항입니다 (특히 ESR가 겹치는 부분이 마음에 듭니다)
피드백:
1. 라이프사이클 그래프를 중앙 페이지에 표시해 주었으면 합니다. 그래야 쉽게 확인할 수 있고, 이상적으로는 EOL 테이블도 함께 제공해 주면 특정 시점에 어떤 버전이 지원 대상이고 어떤 버전이 지원이 종료되었는지 쉽게 파악하고 계획을 세울 수 있을 것입니다 (적어도 ESR의 경우).
2. 스트림 전환:
> [@david](#):
>
> 시스템이 더 성숙해지면 향후 릴리스 스트림 간 전환을 더 쉽게 할 수 있는 방안을 검토할 수 있습니다.
이것은 정말 좋겠습니다 – 하지만 설치를 수행할 때 어떤 태그를 선택할 수만 있어도 큰 도움이 될 것입니다. 아니면 최소한 수동으로 진행하는 단계를 설치 문서에 포함시켜 주셔도 됩니다. 안정판/ESR로 시작하고 싶은 경우, 현재 신규 관리자에게는 어떻게 해야 하는지 명확하지 않습니다. (답변은 `./launcher`에 `--skip-rebuild`를 전달한 후 버전을 수정하고, 처음에 rebuild를 실행하는 것이라고 생각하지만, 확신은 없습니다.) 그렇지 않으면 설치가 최신 버전을 가져와서 실행하는 것으로 바로 진행되므로, 이후로 되돌아가는 것은 문제가 생길 가능성이 높습니다.
(신규 관리자가 겪는 어려움의 예: 현재 “install discourse stable”로 검색했을 때 1위 검색 결과는 [이 스레드](https://meta.discourse.org/t/install-production-ready-stable-on-vps/381224)로 연결되며, 이 스레드는 안정판으로 업그레이드하는 방법을 설명하는 다른 스레드를 링크하지만, 처음부터 안정판을 설치하는 방법은 설명하지 않습니다.)
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [11월 26, 2025, 11:07오전 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/42 "2025-11-26T11:07:47Z")
오늘 우리는 이 RFC를 구현하기 위해 또 한 걸음을 내디뎠습니다. 최신 버전의 Discourse는 `v2025.11.0`으로 지정되었으며, 이제 `latest` 브랜치에서 `v2025.12.0-latest`의 개발을 시작했습니다 🎉
> [@v2025.11.0 릴리스: AI 번역 개선, 채팅 검색, 새 검토 대기열, 이미지 포함 게시물 개선](https://meta.discourse.org/t/release-v2025-11-0-ai-translations-improvements-chat-search-new-review-queue-and-improvements-for-posts-with-images/389615?u=david):
>
> New features in v2025.11.0 New version numbering scheme Perhaps you noticed we just jumped from version 3.6.0.beta2 to version 2025.11.0. We have updated our version numbers for releases to be based on the current year and month as part of a larger project to improve our release processes to provide more choice & predictability for community administrators. [Learn more…](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536)AI translations improvements for search and more authors Localized content can now be served to search engines, making your for…
[이전 페이지](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536.md?page=1)
[다음 페이지](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536.md?page=3)