There hasn’t been any further visible progress on the PR yet:
I’m still hoping the functionality can live in the bundled Events plugin rather than having to maintain it separately.
That previous experience is also why I’m slightly cautious about maintaining this locally for a long time.
On my own self-host I already use an after_code hook for a small upstream PR backport. The hook first checks for markers showing that the functionality has landed upstream. If it hasn’t, it downloads the patch for a known commit, runs git apply --check, and only then applies it with git apply.
That works reasonably well while the patch continues to match core, but I’ve already had an earlier version of that backport stop applying as core moved. A rebuild then failed and the container remained offline until I removed the hook.
For this particular change, if I needed a temporary fallback I would probably provide an after_code backport in the same way rather than package it as a separate plugin.
The reason is that #43187 already modifies the bundled Events plugin’s own scheduled server-side rollover path. An after_code hook can apply essentially the same upstream patch directly during rebuild. A separate plugin would need to recreate that integration through an extension point, or otherwise prepend/override the internal MonitorEventDates behaviour, which adds another layer and could be just as brittle.
The downside of the after_code approach is that it is still tied to the exact shape of the upstream code. Because the successor-topic behaviour touches MonitorEventDates, the same fixed commit patch can continue to be used for as long as git apply --check succeeds. If upstream changes that code enough for the patch context to stop matching, I would need to rebase or adapt the change onto current main, create a new commit, and update the hook to use that new commit SHA.
So my preference remains:
merge the successor functionality into the bundled Events plugin; or
if the team would prefer the behaviour to remain external, expose a supported hook around recurring-event rollover.
Until then, an after_code patch would be a practical temporary self-host fallback, but I wouldn’t regard it as the ideal long-term distribution mechanism.