Bisher gibt es keine sichtbaren weiteren Fortschritte im PR:
Ich hoffe immer noch, dass die Funktion im mitgelieferten Events-Plugin integriert werden kann, anstatt sie separat warten zu müssen.
Diese frühere Erfahrung ist auch der Grund, warum ich etwas vorsichtig bin, dies langfristig lokal zu warten.
Auf meinem eigenen Self-Host benutze ich bereits einen after_code-Hook für ein kleines Upstream-PR-Backport. Der Hook prüft zunächst nach Markierungen, die zeigen, ob die Funktion upstream implementiert wurde. Falls nicht, lädt er den Patch für einen bekannten Commit herunter, führt git apply --check aus und wendet ihn erst dann mit git apply an.
Das funktioniert so lange recht gut, wie der Patch zum Core passt, aber ich hatte bereits eine frühere Version dieses Backports, die nicht mehr angewendet werden konnte, als sich der Core weiterentwickelte. Ein Rebuild schlug dann fehl, und der Container blieb offline, bis ich den Hook entfernte.
Für diese spezifische Änderung würde ich, falls ein temporärer Fallback nötig wäre, wahrscheinlich einen after_code-Backport auf dieselbe Weise bereitstellen, anstatt ihn als separates Plugin zu paketieren.
Der Grund dafür ist, dass #43187 bereits den eigenen serverseitigen Rollover-Pfad des mitgelieferten Events-Plugins modifiziert. Ein after_code-Hook kann im Wesentlichen denselben Upstream-Patch direkt während des Rebuilds anwenden. Ein separates Plugin müsste diese Integration über einen Erweiterungspunkt neu erstellen oder das interne Verhalten von MonitorEventDates anderweitig voranstellen/überschreiben, was eine weitere Ebene hinzufügt und ebenso fragil sein könnte.
Der Nachteil des after_code-Ansatzes ist, dass er immer noch an die genaue Struktur des Upstream-Codes gebunden ist. Da das Verhalten für Nachfolger-Themen MonitorEventDates betrifft, kann derselbe Patch für einen festen Commit so lange verwendet werden, wie git apply --check erfolgreich ist. Wenn Upstream diesen Code so stark ändert, dass der Patch-Kontext nicht mehr passt, müsste ich die Änderung auf den aktuellen main rebasen oder anpassen, einen neuen Commit erstellen und den Hook aktualisieren, um diese neue Commit-SHA zu verwenden.
Meine Präferenz bleibt daher:
die Nachfolger-Funktion in das mitgelieferte Events-Plugin zu integrieren; oder
falls das Team es vorzieht, dass das Verhalten extern bleibt, einen unterstützten Hook rund um den Rollover wiederkehrender Events bereitzustellen.
Bis dahin wäre ein after_code-Patch ein praktischer temporärer Self-Host-Fallback, aber ich würde ihn nicht als ideale langfristige Verteilungsmechanik betrachten.