실제로 의도는 그 반대입니다. 호환성(compat) 브랜치는 ‘출시된’ Discourse 브랜치를 위한 것뿐입니다. Discourse의 latest는 항상 플러그인의 main을 사용합니다. 새로운 기능을 개발하는 곳은 바로 그곳입니다.
즉, 이야기는 다음과 같습니다:
Discourse가 v2026.2를 출시합니다. 플러그인의 GitHub Actions가 이를 자동으로 감지하고 d-compat/v2026.2 브랜치를 생성합니다. 이제 Discourse v2026.2를 사용하는 모든 사람은 내 플러그인의 d-compat/v2026.2 버전을 사용하게 됩니다.
플러그인의 main에서 새 기능을 출시합니다. main 브랜치는 Discourse latest를 실행하는 사람들만 사용하므로 역호환성(backwards-compatibility)에 대해 걱정할 필요가 없습니다.
그리고 와인을 한 잔 더 마시고 있을 때 
, Discourse가 v2026.3을 출시합니다. 처음에는 이 버전에 대한 플러그인 브랜치가 없으므로 main이 사용됩니다. latest를 사용하는 사람들의 경우와 마찬가지로 모든 것이 계속 정상 작동합니다.
몇 시간 내에 GitHub Actions가 새 버전을 감지하고 d-compat/v2026.3을 고정(freeze)합니다. 이제 역호환성에 대한 걱정 없이 main에 다음 플러그인 기능이 올라올 준비가 된 것입니다.
이것은 본질적으로 CDCK에서 테마/플러그인의 안정적 호환성을 처리하기 위해 사용하는 워크플로우입니다. 각 안정 버전 출시 후, 수백 개의 테마/플러그인을 순회하며 .discourse-compatibility를 통해 이를 고정하는 스크립트를 실행합니다. 이 브랜치 기반 제안은 해당 워크플로우의 가벼운 버전이 되기를 목표로 합니다.