La mise à jour des plugins communautaires est soumis à quelques règles qui reprennent les pratiques déjà utilisées sur le noyau.
Règle n°1: proposer vos changements dans une PR
Il faut éviter de mettre à jour directement sur la branche master car:
- cela pollue l’historique en cas d’erreur
- cela permet une relecture dans les pairs
- cela permet de corriger et d’amender si besoin
Règle n°2: éviter les ruptures de compatibilité
Il faut éviter au maximum de changer les bornes basses de compatibilité des plugins car:
- cela complique la maintenance ultérieure car il faudra maintenir plusieurs branches.
On veillera donc à modifier uniquement les bornes basses quand il y a une rupture de compatibilité.
Modifier quelques fonctions dépréciées ne justifient pas de casser la borne basse de compatibilité.
Règle n°3: créer des branches lorsqu’il y a une rupture de compatibilité
Si la rupture de compatibilité est nécessaire, il faut créer créer une branche pour maintenir le plugin dans la version précédente. Cela peut se faire juste avant de merger la PR
Exemple:
J’ai un plugin dont la version est 11.2.5 compatible [3.1.0;4.2.*]
J’ai une modification qui implique un rupture de compatibilité et un passage en SPIP 4.1
- je crée une branche v11 (11 est la valeur X du plugin X.Y.Z)
- je reviens à la branche master et je merge ma PR.
- je change la borne de compatibilité [4.1.0;4.*]
- j’incrémente la valeur X du plugin en lui donnant le numéro de version 12.0.0