Discourse는 LTS 릴리스를 제공하지 않습니다

discourse-compatability에 대해 알지 못했기 때문에, 이 부분은 알아볼 필요가 있겠습니다.

이 문제에 대해 짚고 넘어가고 싶습니다. 왜냐하면 Discourse 팀이 stable을 바라보는 시각과, Discourse 커뮤니티/더 넓은 포럼 관리자 커뮤니티가 Discourse의 stable 제공을 바라보는 시각 사이에 큰 괴리가 있는 것처럼 보이기 때문입니다.

stable이 LTS의 정의를 충족하지 못하는 주요 이유

1) staff는 stable이 언급될 때마다 사용을 적극적으로劝阻하고 있습니다

개별 게시자를 지목하고 싶지는 않지만, staff의 게시물을 통해 이 경향을 보여주는 몇 가지 예시를 꼽아보겠습니다:

tests-passed는 어떤 면에서 stable보다 더 안정적일 수 있습니다. 이는 discourse.org가 실행하는 버전이므로, 가장 잘 테스트된 버전이기 때문입니다.

즉, Discourse는 영구적인 베타 상태에 있으며, 새로운 기능과 개선 작업을 항상 진행 중입니다. 우리의 경우 베타는 불안정함을 의미하지 않습니다. 우리는 tests-passed 및 beta 버전으로 월간 페이지뷰가 수백만 건에 달하는 사이트를 호스팅하고 있습니다.

stable 채널은 반드시 tests-passed보다 더 “안정적”인 것은 아닙니다. 이는 알려진 버그가 있으며, 특정 기능과 개선 사항의 체크포인트 역할을 한다는 개념에 더 가깝습니다. tests-passed에서는 새로운 버그가 도입되었다가 몇 커밋 후에 수정될 수 있습니다.

메시지는 일관되게 Discourse가 ‘영구적인 베타’ 상태라는 것이었습니다. 이는 프로덕션/비개발 사용자가 원하는 경험이 아닙니다.

DuckDuckGo에서 'discourse stable’로 상위 10개 링크를 검색해 보았지만, 그중 stable 사용을 지지하는 내용은 거의 없습니다. 따라서 실제 품질과 무관하게, staff가 일관되게 stable 사용을 지양하도록 안내하고 있다면, 사람들은 목적에 부합하는 제품이라는 인상을 받지 못할 것입니다.

stable이 훌륭할 수 있지만, 반복적으로 사용하지 않는 것이 최선이라는 말을 들으면, 우리는 심각한 배포 환경에서 이를 고려하지 않을 것입니다.

2. LTS는 보안 버그 수정을 넘어 일반 버그 수정도 받습니다

LTS는 기능 업그레이드를 받지 않지만 버그 수정은 받는 것입니다. staff의 자체 코멘트에 따르면, Discourse에서는 보안 문제가 아닌 일반 버그 수정을 백포트하려는 노력이 없어 보입니다. 이것이 사실이 아닐 수도 있지만, 지금까지 우리가 들은 것은 이것이었습니다.

3. LTS는 명확한 설치 단계를 제공합니다

설치 가이드에는 stable의 존재조차 언급되지 않습니다.

4. LTS는 널리 사용됩니다

guest님의 게시물 이전까지는 stable 브랜치의 광범위한 사용 사례를 들어본 적이 없습니다. 실제 현장에서도 널리 사용되고 있을까요? 이렇게 숨겨져 있으므로 그렇지 않다고 의심하지만, 이를 뒷받침할 지표는 없습니다. 이는 프로덕션 배포에 stable을 사용할 때 사람들에게 확신을 주기 때문에 중요한 요인입니다.

5. LTS는 명확한 릴리스 사이클 및 업그레이드 노트를 제공합니다

stable이 명확하게 문서화된 중앙 위치를 찾지 못했습니다. (제가 놓치고 있는 것일 수도 있습니다!)

제가 기대하는 LTS의 문서에는 다음 내용이 포함되어야 합니다:

  • 현재 활성 릴리스 버전
  • 릴리스 노트 (다음 포함):
    • LTS 버전 간 주요 변경 사항/기능
    • 이전 LTS 릴리스에서 마이그레이션 단계 (특히 주의해야 할 깨지는 변경 사항)
  • 각 버전의 계획된 활성 지원 기간

예: mediawiki, 하지만 실제로 대부분의 주요 오픈소스 LTS에는 유사한 페이지가 있습니다.

이러한 문서는 다운타임이 필요하거나/또는 수동 개입이 필요한 깨지는 변경 사항이 있을 때 이를 계획하는 데 도움이 됩니다.

6. LTS는 하나의 릴리스 사이클 내에서 주요 깨지는 변경 사항이 없습니다

stable의 경우 이것이 사실일 수도 있지만, 업그레이드 버튼을 누르면 포럼이 다운되는 경험에 너무 익숙해서 확신할 수 없습니다. 여기서 제가 원하는 것은 무언가를 깨뜨리는 버전 간 전환 시 더 명확한 경고입니다.

7. LTS는 최소한 하나의 전체 LTS 릴리스 사이클 동안 API 비추천(deprecation) 경고를 제공합니다

이것은 월+이 아닌, 년+의 속도로 측정되어야 합니다.

8. LTS는 슬롯이 있거나/중복되는 지원 기간을 가집니다

모든 대형 LTS에는 두 LTS 버전 사이에 지원 기간이 중복되는 시기가 있습니다. stable은 단순히 다음 버전으로 바이너리 전환을 하는 것처럼 보입니다. (중앙 문서 페이지가 없어서 제 인상이 틀렸을 수도 있습니다)

9. 비-LTS에서 LTS로 업그레이드하는 것이 간단합니다

역방향(후퇴)을 지원할 필요는 없지만, LTS가 사용 가능할 때 LTS로 브랜치를 깔끔하게 전환하는 방법이 명확하지 않습니다. 포럼에 이에 대한 게시물이 몇 있는 것 같지만, 다시 말하지만, 제가 찾을 수 있는 중앙 문서화는 없습니다.


저는 Discourse의 팬이지만, 이것은 제가 겪는 일반적인 고통 포인트이자 많은 다른 사람들이 겪는 문제이기도 합니다. 현재 stable은 LTS가 아닌, 그저 브랜치일 뿐입니다.

4개의 좋아요

이 내용을 별도의 주제로 이동했습니다. 플러그인 번들링과는 관련이 없어 보입니다.

4개의 좋아요

관리자 대시보드에서 슬픈 얼굴 표시와 “Update discourse”에서 커밋이 많이 뒤처져 있는 상황을 비교해 보면,

임계 업데이트(critical update)가 tests-passed의 일부인가요? 그리고 “Update All”을 슬픈 얼굴 표시가 뜨기 전에 바로 실행하면 tests-passed와 동기화가 되는 건가요?

이 특정 업데이트는 콘솔에서 다시 빌드해야 한다고 생각합니다. 그것도 두 번이나요.

1개의 좋아요

Discourse는 변경 사항의 속도 면에서 상당히 빠르고, 야심 찬 로드맵을 가지고 있는 것으로 보입니다.

이를 지원하기 위해서는 많은 사용자 피드백이 필요합니다. 새로운 변경 사항에 대한 초기 피드백을 지원하기 위해 tests-passed 브랜치를 장려하는 것이 명확한 암묵적 전략이라고 생각합니다.

그 대가로 사용자는 무료 소프트웨어와 새로운 기능을 얻습니다. 일종의 계약이죠. 시간이 지나면서 이러한 거래가 성공적이었던 것으로 입증된 것 같습니다.

Stable 빌드는 개발에 크게 도움이 되지 않으므로, 이를 크게 장려하는 것이 비즈니스 관점에서 유리하지 않을 수 있습니다(전적으로 제 개인적인 의견이며, CDCK를 대변하는 것이 아닙니다).

Stable 버전의 또 다른 문제는 이 점이며, 이는 더욱 중요합니다:

Stable 버전 사이에는 중요한 비권장(deprecation) 및 API 변경을 포함한 많은 변경 사항이 있습니다. 개발자, 사이트 관리자 또는 테마 제작자로서 tests-passed에 참여하면, 다음 stable 마일스톤에 도달할 때마다 거대한 산을 오르는 대신, 변경 사항을 작은 조각으로 나눠서 처리할 기회를 가질 수 있습니다.

이러한 큰 버전 업그레이드를 지원하려면 스테이징 사이트와 테스트 케이스를 통과하기 위한 상당한 준비가 필요할 것입니다.

직접 커스터마이징을 하지 않는다면 stable 버전을 선택할 수 있지만, 다음 업그레이드 시점에 사용 중인 애드온이 충분히 유지보수되고 있는지 확인해야 하는 타인에 크게 의존하게 됩니다. 업그레이드 시점에 일부 요소의 지원이 중단되어 난감한 상황에 처할 수도 있습니다. 또한 개발자가 stable 버전을 아예 지원하지 않아 플러그인의 "cut"을 만들어 stable 빌드를 지원해야 할 수도 있습니다. (다만, 좋은 고정(pinning) 시스템이 마련되어 있어 큰 작업은 아닙니다.)

Discourse의 또 다른 중요한 특징은 단위 테스트가 매우 집중되어 있다는 점입니다. 따라서 tests-passed 브랜치는 안정성 측면에서 보통 매우 좋습니다.

5개의 좋아요

관리진이 플러그인 번들링 같은 인기 없는 변경 사항을 되돌리지 않는 것을 고려할 때, 이 부분은 정확하지 않다고 생각합니다. 아마도 QA 관점에서는 그럴 수 있겠지만, 과거에도 꽤 난감한 버그들이 수정되지 않은 경우가 여러 번 있었습니다. 결국 시간과 돈을 투자하는 쪽이 그들이므로 결정은 그들의 몫이지만, 제 생각에는 피드백을 더 얻기 위한 전략은 아닌 것 같습니다.

적절한 LTS를 지원하지 않는 더 현실적인 이유는, 팀의 누군가가 이를 관리하고 문서화하는 데 시간이 들기 때문일 것입니다. 이는 주로 셀프 호스터에게 이점이 되는 기능이므로, 그들에게는 시간 낭비로 여겨질 가능성이 높습니다. 하지만 이는 일종의 기대되는 기능이며, 다른 동시대 제품들이 더 안정적인 옵션을 제공한다는 점을 고려할 때, 포럼 관리자가 포럼 소프트웨어를 선택할 때 이것이 없는 것은 실질적인 단점이 됩니다.

반대로, 플러그인 번들링은 플러그인의 사용을 장려하고, 그 결과 더 많은 피드백을 확보하기 위한 조치라고 생각합니다.

관리진은 다른 스레드에서 버전 불일치로 인한 개발 팀의 생산성 저하 문제를 구체적으로 지적했습니다. 이는 타당한 근거이지만, 다른 스레드에서 논의된 바와 같이 근본 문제를 해결하는 이상적인 방법은 아닙니다.