여전히 이 기능이 별도로 유지 관리되는 것이 아니라 번들된 Events 플러그인 안에 포함되기를 희망하고 있습니다.
그 이전 경험 때문에 이 기능을 장기간 로컬에서 유지 관리하는 것에 대해 다소 신중하게 접근하고 있습니다.
제 자가 호스팅 환경에서는 이미 작은 업스트림 PR 백포트를 위해 after_code 훅을 사용하고 있습니다. 이 훅은 해당 기능이 업스트림에 이미 반영되었는지를 나타내는 마커를 먼저 확인합니다. 만약 반영되지 않았다면, 알려진 커밋에 대한 패치를 다운로드하고 git apply --check를 실행한 후, 그 다음에야 git apply로 적용합니다.
패치가 코어와 계속 일치하는 동안에는 이 방식이 꽤 잘 작동하지만, 코어가 이동하면서 해당 백포트의 이전 버전이 더 이상 적용되지 않는 경우가 이미 있었습니다. 그 결과 재빌드가 실패했고, 훅을 제거할 때까지 컨테이너가 오프라인 상태였습니다.
이 특정 변경 사항의 경우, 임시 폴백이 필요할 경우 별도의 플러그인으로 패키징하는 대신 동일한 방식으로 after_code 백포트를 제공할 가능성이 높습니다.
그 이유는 #43187이 이미 번들된 Events 플러그인 자체의 예약된 서버 측 롤오버(rollover) 경로를 수정하고 있기 때문입니다. after_code 훅은 재빌드 중에 기본적으로 동일한 업스트림 패치를 직접 적용할 수 있습니다. 반면 별도의 플러그인은 확장 지점을 통해 그 통합을 재현하거나, 내부 MonitorEventDates 동작을 앞에 붙이거나 오버라이드해야 하므로, 이는 또 다른 계층을 추가하고 동일한 정도로 취약할 수 있습니다.
after_code 방식의 단점은 여전히 업스트림 코드의 정확한 형태에 종속된다는 것입니다. 후속 주제(successor-topic) 동작이 MonitorEventDates에 영향을 미치므로, git apply --check가 성공하는 한 동일한 고정 커밋 패치를 계속 사용할 수 있습니다. 만약 업스트림이 패치 컨텍스트가 더 이상 일치하지 않을 정도로 코드를 변경한다면, 현재 main으로 변경 사항을 리베이스하거나 적응시키고, 새로운 커밋을 생성한 후, 훅을 해당 새로운 커밋 SHA를 사용하도록 업데이트해야 합니다.
따라서 제 선호도는 여전히 다음과 같습니다:
후속 기능을 번들된 Events 플러그인에 병합하거나;
팀이 이 동작이 외부에 남아 있기를 원한다면, 반복 이벤트 롤오버 주위에 지원되는 훅을 노출하십시오.
그때까지, after_code 패치는 실용적인 임시 자가 호스팅 폴백이 될 수 있지만, 이를 이상적인 장기 배포 메커니즘으로 보지는 않습니다.