여기서 현실은 stable 브랜치가 실제로 LTS이며, 꽤 좋은 LTS라는 점입니다. 보안 업데이트를 제공하며, 어떤 플러그인 버전이 이 브랜치와 호환되는지 매우 명확합니다(.discourse-compatibility 파일 덕분에). 이 모든 것이 제대로 작동하기까지 오랜 시간이 걸렸다는 점은 완전히 인정합니다. 하지만 지난 2년 정도 동안에는 잘 작동해 왔는데, 이는 팀의 훌륭한 성과입니다.
이제 발언의 두 번째 부분입니다. stable이 원하지 않는 것으로 종종 표현되는 것은 사실입니다. 하지만 Communiteq 호스팅에서는 지난 2년 6개월 동안 클라이언트에게 stable(“안정성 우선, 연간 2회 새로운 업데이트, 월 1회 보안 업데이트”)와 tests-passed(“항상 최전선, 월 1회 새로운 기능”) 사이에서 자유롭게 선택할 수 있게 해 왔으며, 85%가 stable을 선택합니다.
그 점은 이해합니다. 하지만 그것은 개발 문제이지 프로덕션 문제가 아닌 것 아닌가요? 개발 환경에서 그렇게 하는 것은 완전히 이해할 수 있습니다. 하지만 기본 프로덕션 설치에 해당 플러그인들을 추가하는 것은 플러그인이라는 개념(정의상 기본이 아닌 것)의 취지를 무색하게 만듭니다.
제가 보는 유일한 실질적인 프로덕션상의 이점은 플러그인 제거와 멀티사이트 호스트와 관련된 매우, 매우 특수한 사례입니다. (다시 말하지만, 이것은 좋은 일이며, 다른 모든 프로덕션 문제는 시간이 지남에 따라 해결되었습니다!)
그것은 사용자가 확인할 수 있는 플러그인 목록을 표시하고 app.yml에 추가하도록 하는 설정 스크립트로도 해결할 수 있었습니다.
하지만 여전히 다른 티어에 대해 다른 (부분) 플러그인 세트를 제공하고 있죠?