Open Time

La question posée hier par Philippe m’a donné une idée à laquelle je réfléchis depuis (l’emphase est de moi) :

Le plugin dcProxyV2 est-il destiné à assurer une rétrocompatibilité pour les thèmes et plugins ?

J’ai répondu ceci :

Ce plugin est utilisé pour apporter une compatibilité avec les behaviors dont la signature a changé pour la 2.24, et pour quelques autres fonctions utilitaires.

Mais à mon avis ça ne suffira pas à résoudre tous les problèmes, en particulier avec le typage des arguments des fonctions de Dotclear.

Et c’est bien là que je bloque parce qu’il y a deux possibilités :

1. Laisser en l’état, faire en sorte qu’on puisse redémarrer Dotclear en mode sans échec qui permette de mettre à jour, voire de désactiver de façon permanente les plugins soupçonnés de ne pas fonctionner avec la prochaine 2.24.

2. Ajouter dans le plugin dcProxyV2 une interface avec toutes les méthodes et fonctions ayant changé de signature¹, ce qui implique de modifier tout le cœur de Dotclear pour, par exemple, utiliser des noms de classe et, ou, des noms de méthodes et fonctions différents.

J’avoue qu’à ce stade je suis partagé entre deux sentiments :

1. J’ai déjà fourni un boulot assez conséquent dans la reprise du code de Dotclear depuis quelques semaines — voire quelques mois — et je ne vais pas, en plus, refaire tout le chemin inverse — façon de parler — pour faire en sorte que ce soit transparent pour le développeur de plugin².

2. Ça la fout mal si, dès que la mise à jour sera effectuée, l’installation plante et le ou les blogs ne sont plus accessibles. Cela dit je pourrais faire en sorte que la mise à jour se finisse par un redémarrage en mode sans échec, pour donner le temps d’agir sur les plugins récalcitrants…

On pourrait imaginer d’ajouter une propriété aux plugins (et aux thèmes) qui définirait la version max de Dotclear avec laquelle ils sont validés/compatibles/testés et par exemple désactiver tout ceux qui ne comportent pas cette indication ou qui indique une version moins récente. Mais qui va faire ce boulot de modification de tous les plugins disponibles sur DotAddict (à part les miens et quelques autres) ?

En fait ça ne résout pas grand chose…

Pour reprendre les deux points :

1. Le code tel qu’il est, ou tel qu’il sera pour la prochaine version, commence à avoir une gueule sympa³ — c’est très subjectif de ma part, mais bon. De plus je me rapproche tranquillement de ce qu’a fait JcDenis depuis quelques mois sur la branche namespace (possiblement Dotclear 3.0).

2. Si je rajoute un proxy pour les classes et méthodes/fonctions, ça me permet aussi de me rapprocher en particulier des noms de classe choisis par JcDenis. Ça milite pour une future convergence. Par contre le code va gonfler de manière conséquente et je n’avais pas dans l’idée de conserver de façon pérenne le plugin dcProxyV2.

Il me reste encore du code à finir de reprendre du côté de l’admin (c’est quasi fini et pas loin d’être poussé sur le dépôt) et il me restera encore les plugins et thèmes de la distribution à revoir avant d’en avoir, a priori, terminé avec cette copieuse revue.

Dit autrement il reste encore une ou deux semaines avant qu’il faille que je prenne une décision, alors dites-moi ce que vous en pensez d’ici là ; sinon je choisirai probablement la casse⁴, mais je peux encore changer d’idée…

Maintenant peut-être qu’il existe une troisième possibilité intermédiaire que je n’aurais pas imaginée ?

PS : Les plugins que j’ai développés ou que je maintiens et qui nécessiteront une mise à jour seront disponibles au moment de la sortie de la 2.24 ; donc prêts à être mis à jour. La question se posera pour les autres.