Non ci sono stati ulteriori progressi visibili sulla PR:
Spero ancora che la funzionalità possa risiedere nel plugin Events incluso, piuttosto che doverla mantenere separatamente.
Quella precedente esperienza è anche il motivo per cui sono leggermente cauto nel mantenere questa modifica localmente per un lungo periodo.
Sul mio self-host già uso un hook after_code per un piccolo backport di una PR upstream. L’hook prima controlla la presenza di marker che indicano che la funzionalità è stata integrata upstream. Se non lo è, scarica la patch per un commit noto, esegue git apply --check e solo allora la applica con git apply.
Questo funziona abbastanza bene finché la patch continua a corrispondere al core, ma ho già avuto un caso in cui una versione precedente di quel backport ha smesso di applicarsi man mano che il core si evolveva. Una rebuild ha quindi fallito e il container è rimasto offline finché non ho rimosso l’hook.
Per questa modifica in particolare, se avessi bisogno di una soluzione temporanea, probabilmente fornirei un backport tramite after_code nello stesso modo, piuttosto che imballarlo come plugin separato.
Il motivo è che la #43187 modifica già il percorso di rollover lato server previsto dal plugin Events incluso. Un hook after_code può applicare essenzialmente la stessa patch upstream direttamente durante la rebuild. Un plugin separato dovrebbe ricreare quell’integrazione tramite un punto di estensione, oppure sovrascrivere/prependere il comportamento interno di MonitorEventDates, il che aggiunge un altro livello e potrebbe essere altrettanto fragile.
Lo svantaggio dell’approccio after_code è che è ancora legato alla struttura esatta del codice upstream. Poiché il comportamento dei topic successori tocca MonitorEventDates, la stessa patch per un commit fisso può continuare a essere utilizzata finché git apply --check ha esito positivo. Se upstream modifica quel codice abbastanza da far sì che il contesto della patch non corrisponda più, dovrei rifare il rebase o adattare la modifica alla main attuale, creare un nuovo commit e aggiornare l’hook per usare quel nuovo SHA di commit.
Quindi la mia preferenza rimane:
integrare la funzionalità dei successori nel plugin Events incluso; oppure
se il team preferisce che il comportamento rimanga esterno, esporre un hook supportato attorno al rollover degli eventi ricorrenti.
Fino ad allora, una patch after_code sarebbe una soluzione temporanea pratica per chi usa il self-host, ma non la considererei il meccanismo di distribuzione ideale a lungo termine.