현재 런처 툴링과 이 새로운 브랜치 구조를 사용하면, 다음과 같은 방식으로 업그레이드 시기를 제어할 수 있습니다:
- v2026.02 릴리스
app.yml파일에서version: release/v2026.02로 설정- v2026.03 릴리스
- 재빌드(rebuild)를 실행합니다. 여전히 2026.02 버전을 유지하며, 최근의 보안 패치가 적용됩니다.
- 준비가 되면
app.yml에서version: release/v2026.03로 변경합니다.
하지만 매월 수동으로 app.yml을 편집하는 것은 이상적이지 않으므로, 프로세스를 더 사용자 친화적으로 만들 수 있는 시스템을 설계할 수 있기를 바랍니다.
OP(최초 게시자)의 프로세스는 브랜치를 실제 릴리스로 표시하기 전에 '릴리스 후보(release candidate)'로 취급할 수 있게 해줍니다. 이 기능을 정확히 어떻게/사용할지는 아직 명확하지 않으며, 새로운 시스템에 익숙해지면서 발전할 부분이 아닐까 생각합니다.
우리는 디스커스(Discourse) 개발의 속도와 광범위한 커스텀화를 가진 사용자들의 안정성 사이에서 균형을 맞추려 하고 있습니다. 기능들이 고객에게 전달되기까지 3개월 이상의 지연은 선택지가 아닙니다. 오히려 월간 릴리스는 우리에게 느린 편에 속합니다. 현재로써는 대부분의 호스팅에 latest를 사용하려는 의도를 가지고 있습니다.
하지만 물론, 디스커스를 자체 호스팅하는 사용자들의 경우 변경 사항이 덜 빈번하기를 원하는 점을 이해합니다. 그래서 ESR 릴리스가 중요한 역할을 하게 됩니다.