Hello,
Je commence à mettre à jour la compat des plugins que je maintiens mais je me pose pas mal de questions.
En outre, je vois passer des mises à jour sur d’autres plugins et on est pas très raccord sur la stratégie à adopter.
Je me dis que ça serait bien de définir quelques recommandations pour éviter la joyeuse kermesse à la fin…
En effet, il y a plusieurs « améliorations » qu’il est possible d’amener à nos plugins qui vont entrer dans le futur:
1- l’abandon du plugin.xml qui n’est plus nécessaire à partir de la branche 3.0
2- l’utilisation d’un logo svg pour le plugin à partir de la branche 3.2
3- passer le logo à la racine du plugin avec un nom prefixe.svg à partir de 3.2
4- l’ajout de necessite vers des plugins-dist retirés depuis la 4.0 (ce qui aurait toujours dû être le cas même avant la 4.0)
cas 1: plugin compat [3.2.0;3.2.]
Dans ce cas, normalement il n’existe plus de plugin.xml et on peut appliquer 2 et 3.
Si on ne souhaite pas utiliser des nouveautés spip 4 on peut donc passer à [3.2.0;4.0.].
Sinon on crée une branche nouvelle (via le master) [4.0.0-alpha;4.0.*].
cas 2: plugin compat [3.1.0;3.2.] ou [3.0.0;3.2.]
Dans ce cas, normalement il n’existe plus de plugin.xml, sinon on peut le virer, ça doit être un oubli.
2 n’est pas applicable pour 3.0 et 3.1 qui ne sont plus supportées par spip suite à la sortie de la 4.0.
Le mieux est sûrement de créer une nouvelle branche n+1 du plugin compatible [3.2.0;4.0.] et d’appliquer 2 et 3 si pas de besoin de nouveautés spip 4.
La branche n peut être réduite à [3.0.0;3.1.] ou [3.1.0;3.1.] selon.
Si on a besoin de nouveautés spip 4 alors on crée une branche nouvelle (via le master) [4.0.0-alpha;4.0.], application de 2 et 3 et la branche n ne change pas.
cas 3: plugin compat [2.x.y;3.2.*]
Dans ce cas, il faut créer une branche n+1 comme dans le cas 2 en appliquant 1, 2 et 3.
La branche n peut rester comme elle est ou être réduite à 3.1 max.
A votre avis ? C’est vraiment une première réflexion à améliorer je pense.