플러그인에 버전 번호를 부여하여, 플러그인 목록에서 해당 플러그인이 호환되는 Discourse의 최소 및 최대 버전을 표시할 수 있는지 궁금합니다.
이렇게 하면 플러그인은 업데이트되었는데 Discourse 버전이 뒤처져 있어 사이트 전체가 깨지는 상황을 방지할 수 있습니다.
플러그인과 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 플러그인 사용에 집중하시라고 제안합니다. 공식 플러그인의 경우, 코어와 호환성을 추적하기 위한 프로세스가 이미 마련되어 있으므로 기능 요청은 불필요하다고 생각합니다.
7개의 좋아요
플러그인의 최대 호환 버전을 어떻게 정의할 수 있을지 잘 모르겠습니다. 단순한 플러그인은 최소한 4.0까지 작동한다고 선언할 수 있을 것입니다. 그리고 4.0이 출시되었을 때, CDCK가 호환성이 깨지는 변경 사항(breaking changes)을 도입하지 않았다면 여전히 작동할 수도 있습니다.
하지만 만약 그 단순한 플러그인이 3.8에서 CDCK가 비추천(deprecated)으로 표시하고 3.10에서 제거한 어떤 것을 사용했다면… 이런 상황을 고려하는 것은 꽤 어렵습니다.
정의할 수 없기 때문입니다.
다음 커밋이 릴리스되는 즉시 구식이 됩니다.
하지만 원리는 간단합니다:
- 포괄적인(95% 커버리지) 플러그인 테스트(백엔드 및 시스템 최소 사양)가 코어의 모든 새 커밋에서 CI에서 실행됩니다.
그리고 설치 전에 녹색 체크 표시를 확인하세요.
이 문제를 두고 이것저것 시도해 보다가 GitHub에서 해결책을 찾았습니다.
즉, 최근 CI 작업에 대한 녹색 체크 표시만으로는 충분하지 않습니다. 최근에 변경 사항이 있어 플러그인이 깨질 수 있기 때문입니다. 기본적으로 Discourse가 브랜치를 업데이트할 때 CI 작업을 다시 실행해야 합니다.
이 예시 저장소에서 효율적인 해결책을 마련했습니다. 기본적으로 Discourse 저장소의 중요한 브랜치를 확인하여 변경 사항이 있는지 보는 예약된 워크플로우입니다. 변경 사항이 있으면 테스트 스위트를 실행해야 하는 일반 CI 워크플로우를 트리거합니다. 그런 다음 readme에 배지를 배치하여 최신 변경 사항에 대해 CI 워크플로우가 어떻게 실행되었는지 보여줄 수 있습니다.
모니터링 워크플로우는 몇 초 만에 실행됩니다. 따라서 예약 시 GitHub Action 시간을 1분만 소모하게 됩니다.
물론 이 전체 설정의 신뢰성은 플러그인/테마 컴포넌트 개발자가 좋은 테스트 스위트를 만드는 데 기울이는 노력에 달려 있습니다.
또한 Discourse의 “업데이트” 페이지에서 특정 버전의 최신 CI 작업이 실패했는지 여부를 알 수 없는 UX 문제가 여전히 남아 있습니다.
따라서 Discourse 브랜치가 변경될 때 플러그인을 다시 빌드하는 모니터링 워크플로우를 갖추는 것 외에도, 결과(성공/실패)를 기록하는 빌드 아티팩트를 생성해야 합니다. 플러그인 메타데이터에서 이 아티팩트를 가리킬 수 있어야 하며, Discourse는 업데이트 인터페이스에서 호환성/결과를 표시하기 위해 이 아티팩트를 가져와야 합니다.
이것은 foolproof(완벽한) 구성은 아니지만, 어쨌든 어떤 해결책은 됩니다.
그래서 "CI에서 코어의 모든 새 커밋마다"라고 쓴 거예요 
Pavilion에서 이 모든 것을 정확히 수행하는 대시보드를 오랫동안 가지고 있었습니다.