# 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:** 1
**Showing post:** 16

<div class="post-metadata">

### Author: ![schneeland](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/schneeland/32/275391_2.png) [@schneeland](https://meta.discourse.org/u/schneeland)
#### Post date: [9월 24, 2025, 8:25오후 UTC](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536/16 "2025-09-24T20:25:12Z")

</div>

다른 분들의 의견에 동의합니다. 제안된 변경 사항의 방향성이 좋습니다. 또한 제안된 브랜치 이름이 기존 이름보다 훨씬 직관적이라고 생각합니다. 👍

아직 명확하지 않은 점은 `release`와 `esr` 브랜치(`latest`는 직관적으로 보입니다)의 업그레이드 프로세스가 어떻게 작동하는지입니다. 말씀하신 대로, 시점마다 현재 릴리스(이를 `n`이라고 하겠습니다)와 이전 릴리스(`n-1`)가 모두 지원되며, 관리자로서 언제 업그레이드할지 선택할 수 있다고 하셨죠.

다른 소프트웨어를 사용해 본 제 경험에 비추어 보면, 새 릴리스 버전(`n+1`)이 나올 때 버전 `n+1`의 사용 가능 여부를 알리는 알림을 받습니다. 그리고 그 후 메이저 업그레이드(Linux의 `apt dist-upgrade`와 유사)를 수행하거나, 마이너/표준 업데이트(Linux의 `apt upgrade`와 유사)를 수행하여 버전 `n`에 머물러 있을지 결정할 수 있었습니다. 이것이 Discourse 런처 스크립트에 구현될 기능인가요?

또한, 릴리스 의식/프로세스를 최소화하려는 의도는 이해하지만, 제 직관으로는 일반 릴리스와 ESR 릴리스 모두 출시 전에 최소한 추가 테스트를 거치기를 원합니다. 이는 엔터프라이즈 IT 분야에서 일한 기간이 너무 길어서 그런 편견일 수도 있습니다. 😄

마지막으로, 월간 릴리스가 실제로는 “너무 빠르지는” 않은지 궁금합니다. 이는 인정하건대 주관적인 의견이기도 하지만, 부업으로 IT 업무를 관리하는 자원봉사자로서의 제 경험을 볼 때, 매월 큰 업데이트를 처리할 시간이 없을 수도 있습니다. 그리고 그 점을 고려해 볼 때, Discourse 개발자로서 여러분의 업무를 좀 더 쉽게 만들어 주려면 분기별로만 릴리스하고, 별도의 `esr` 브랜치 없이 `release` 브랜치만 유지하는 것도 하나의 방법이 될 수 있지 않을까 생각해 봅니다.

---

_[View the full topic](https://meta.discourse.org/t/rfc-a-new-versioning-strategy-for-discourse/383536)._