Avez-vous des nouvelles à ce sujet ? J’adore la fonctionnalité des événements récurrents, mais je souffre d’avoir à gérer manuellement et fréquemment l’archivage des événements !
2 « J'aime »
Il n’y a pas eu d’avancée visible supplémentaire sur la PR pour le moment :
J’espère toujours que cette fonctionnalité pourra être intégrée au plugin Events inclus, plutôt que de devoir la maintenir séparément.
Cette expérience antérieure est aussi la raison pour laquelle je suis légèrement prudent à l’idée de maintenir cela localement sur le long terme.
Sur mon propre serveur auto-hébergé, j’utilise déjà un hook after_code pour un petit backport de PR amont. Le hook vérifie d’abord la présence de marqueurs indiquant que la fonctionnalité a été intégrée en amont. Si ce n’est pas le cas, il télécharge le patch pour un commit connu, exécute git apply --check, et ne l’applique qu’ensuite avec git apply.
Cela fonctionne assez bien tant que le patch correspond au cœur, mais j’ai déjà eu une version antérieure de ce backport qui a cessé de s’appliquer lorsque le cœur a évolué. Une reconstruction a alors échoué et le conteneur est resté hors ligne jusqu’à ce que je supprime le hook.
Pour ce changement particulier, si j’avais besoin d’une solution de repli temporaire, je fournirais probablement un backport via after_code de la même manière, plutôt que de l’emballer en tant que plugin séparé.
La raison est que #43187 modifie déjà le chemin de bascule planifié côté serveur du plugin Events inclus lui-même. Un hook after_code peut appliquer essentiellement le même patch amont directement lors de la reconstruction. Un plugin séparé devrait recréer cette intégration via un point d’extension, ou autrement préfixer/surcharger le comportement interne de MonitorEventDates, ce qui ajoute une couche supplémentaire et pourrait être tout aussi fragile.
L’inconvénient de l’approche after_code est qu’elle reste liée à la forme exacte du code amont. Comme le comportement du sujet successeur touche à MonitorEventDates, le même patch de commit fixe peut continuer à être utilisé aussi longtemps que git apply --check réussit. Si l’amont modifie suffisamment ce code pour que le contexte du patch ne corresponde plus, il faudra que je fasse un rebase ou que j’adapte le changement à la branche main actuelle, crée un nouveau commit, et mette à jour le hook pour utiliser ce nouveau SHA de commit.
Donc ma préférence reste :
- fusionner la fonctionnalité de successeur dans le plugin Events inclus ; ou
- si l’équipe préfère que le comportement reste externe, exposer un hook pris en charge autour de la bascule des événements récurrents.
En attendant, un patch after_code serait une solution de repli temporaire pratique pour l’auto-hébergement, mais je ne le considérerais pas comme le mécanisme de distribution idéal à long terme.
3 « J'aime »