Есть ли какие-либо новости по этому вопросу? Мне очень нравится функция повторяющихся событий, но я постоянно сталкиваюсь с проблемой: приходится вручную и довольно часто заниматься архивированием событий!
2 лайка
Пока не видно какого-либо дальнейшего прогресса по PR:
Я по-прежнему надеюсь, что эта функциональность будет реализована в встроенном плагине Events, а не потребует отдельного обслуживания.
Этот прошлый опыт также заставляет меня немного осторожничать с тем, чтобы поддерживать это локально в течение длительного времени.
В моём собственном self-host я уже использую хук after_code для небольшого бэкпорта из PR upstream. Сначала хук проверяет маркеры, показывающие, что функциональность уже появилась в upstream. Если её нет, он скачивает патч для известного коммита, выполняет git apply --check и только затем применяет его с помощью git apply.
Это работает достаточно хорошо, пока патч продолжает соответствовать ядру, но у меня уже была ситуация, когда более ранняя версия этого бэкпорта перестала применяться по мере развития ядра. Тогда сборка завершилась ошибкой, и контейнер оставался офлайн, пока я не удалил хук.
Для этого конкретного изменения, если мне понадобится временный запасной вариант, я, вероятно, предоставлю бэкпорт через after_code тем же способом, а не упаковывал бы его как отдельный плагин.
Причина в том, что #43187 уже модифицирует собственный серверный путь планового переноса (rollover) во встроенном плагине Events. Хук after_code может применить практически тот же самый патч из upstream непосредственно во время пересборки. Отдельный плагин потребовал бы воссоздать эту интеграцию через точку расширения или иным образом переопределить/подменить внутреннее поведение MonitorEventDates, что добавит ещё один слой и может оказаться таким же хрупким.
Недостаток подхода с after_code заключается в том, что он по-прежнему привязан к точной структуре кода upstream. Поскольку поведение темы-преемника затрагивает MonitorEventDates, тот же самый патч для фиксированного коммита может продолжать использоваться, пока git apply --check успешен. Если upstream достаточно изменит этот код, и контекст патча перестанет совпадать, мне придётся перебазить или адаптировать изменения под текущий main, создать новый коммит и обновить хук, чтобы использовать этот новый SHA коммита.
Таким образом, моё предпочтение остаётся прежним:
- слить функциональность темы-преемника во встроенный плагин Events; или
- если команда предпочитает, чтобы это поведение оставалось внешним, предоставить поддерживаемый хук вокруг переноса (rollover) повторяющихся событий.
До тех пор, пока этого не произойдёт, патч через after_code будет практичным временным решением для self-host, но я не считаю его идеальным механизмом долгосрочного распространения.
3 лайка