플러그인과 TC(테마 컴포넌트)는 크게 두 가지 범주로 나뉩니다:
- 공식(Official)
- 서드파티(Third Party)
공식 플러그인은 이미 호환성이 유지되고 있으며, 호환되지 않는 경우가 있더라도 보통 급여를 받는 개발자가 며칠 안에 문제를 해결합니다.
서드파티 플러그인
유지보수자가 호환성을 유지하는 것만으로도 이미 쉽지 않은데, 호환되는지 여부까지 추적하는 것은 더더욱 어렵습니다.
실제로 유지보수하기에 실질적인 버전은 단 두 가지뿐입니다:
- 최신
stable - 최신
tests-passed
핀 고정(pinning) 시스템(Pinning plugin and theme versions for older Discourse installs (d-compat branches))을 사용하여 이미 stable 버전에 대한 핀 고정을 사용할 수 있습니다. 이를 통해 명시적인 호환성을 표시하도록 표면화하는 것도 꽤 좋을 수 있지만, 핀이 없더라도 플러그인이 호환되지 않는다는 뜻은 아닙니다.
최신 버전과의 호환성은 GitHub의 CI에서 녹색 체크 표시로 표시될 수 있습니다.
이것은 두 가지 요소에 의존합니다:
- 철저한 CI 설정(이상적으로는 Discourse 플러그인 표준에 기반한 것)
- 매우 높은 테스트 커버리지
후자는 무상으로 작업을 수행하는 서드파티 유지보수자에게는 큰 요구사항입니다.
비공식 플러그인의 경우, 기능 요청은 결국 서드파티 플러그인에 대한 적절한 자금 지원으로 귀결됩니다.
경험이 풍부한 플러그인 작성자로서, 서드파티 플러그인에 자금을 조달하는 것은 거의 불가능하다고 말씀드릴 수 있습니다.
제 플러그인이 여전히 작동하는 유일한 이유는 다음과 같습니다:
- 제가 직접 사용하고 있기 때문
- 생태계 내 평판을 유지하기 위한 수단이기 때문
이것은 저에게 가치 있지만, 그에는 한계가 있습니다.
서드파티 플러그인 개발은 Discourse 생태계에서 거의 
상태에 가깝다고 생각합니다. 코어의 매우 까다로운 발전 속도에 맞춰 시스템을 유지할 수 있는 개발자는 극소수에 불과하기 때문입니다.
다른 예외:
- Communiteq와 같은 대형 호스팅 업체에서 사용하는 플러그인 - 아마도 그들의 의견이 있을 수 있지만 - 하지만 그들 역시 대부분의 고객이 원하는 것에 초점을 맞춰야 하며, 자원에도 한계가 있습니다.
- 구독 시스템이 연결된 Custom Wizard & Events 플러그인 - 다시 한번 Angus에게 이것이 어디로 향하고 있는지 의견을 구해볼 수 있습니다.
요약
결국 공식 플러그인(그리고 저나 Communiteq와 같이 매우 활발하게 활동하는 소수의 개발자의 플러그인)의 호환성만 신뢰할 수 있다는 점을 고려할 때, 저는 단순히 official 플러그인 사용에 집중하시라고 제안합니다. 공식 플러그인의 경우, 코어와 호환성을 추적하기 위한 프로세스가 이미 마련되어 있으므로 기능 요청은 불필요하다고 생각합니다.