¿Hay algún avance en esto? Aunque me encanta la funcionalidad de eventos recurrentes, ¡me duele tener que gestionar manualmente el archivo de los eventos con tanta frecuencia!
2 Me gusta
Aún no se ha visto ningún progreso adicional en la PR:
Sigo esperando que la funcionalidad pueda residir en el plugin de Eventos incluido, en lugar de tener que mantenerla por separado.
Esa experiencia previa es también la razón por la que soy algo cauteloso con respecto a mantener esto localmente durante mucho tiempo.
En mi propia instancia autoalojada ya uso un hook de after_code para un pequeño backport de una PR upstream. El hook primero verifica marcadores que indiquen que la funcionalidad ha llegado upstream. Si no ha llegado, descarga el parche para un commit conocido, ejecuta git apply --check y solo entonces lo aplica con git apply.
Eso funciona razonablemente bien mientras el parche siga coincidiendo con el núcleo, pero ya he tenido una versión anterior de ese backport que dejó de aplicarse a medida que el núcleo avanzaba. Entonces, una reconstrucción falló y el contenedor permaneció fuera de línea hasta que eliminé el hook.
Para este cambio en particular, si necesitara una solución temporal de respaldo, probablemente proporcionaría un backport de after_code de la misma manera, en lugar de empaquetarlo como un plugin separado.
La razón es que #43187 ya modifica la propia ruta de cambio de fecha programado en el servidor del plugin de Eventos incluido. Un hook de after_code puede aplicar esencialmente el mismo parche upstream directamente durante la reconstrucción. Un plugin separado necesitaría recrear esa integración a través de un punto de extensión, o de otra manera antepone/sobrescribe el comportamiento interno de MonitorEventDates, lo que añade otra capa y podría ser igual de frágil.
La desventaja del enfoque de after_code es que sigue atado a la forma exacta del código upstream. Dado que el comportamiento de tema sucesor afecta a MonitorEventDates, el mismo parche de commit fijo puede seguir usándose durante tanto tiempo como git apply --check tenga éxito. Si upstream cambia ese código lo suficiente para que el contexto del parche deje de coincidir, necesitaría rebasear o adaptar el cambio al main actual, crear un nuevo commit y actualizar el hook para usar ese nuevo SHA de commit.
Por lo tanto, mi preferencia sigue siendo:
- fusionar la funcionalidad de sucesor en el plugin de Eventos incluido; o
- si el equipo prefiere que el comportamiento permanezca externo, exponer un hook soportado alrededor del cambio de fecha de eventos recurrentes.
Hasta entonces, un parche de after_code sería una solución temporal práctica para autoalojamiento, pero no lo consideraría el mecanismo de distribución ideal a largo plazo.
1 me gusta