Les dépôts git spip/*, spip-league/* et seenthis/* suivent la gestion sémantique de version
Il ne s’agit pas seulement de mettre à jour l’attribut version (et le tag) avec 3 digits subjectivement, mais aussi (et surtout) de fournir un élément technique important pour les algorithmes (le gestionnaire de plugins de spip, svp pour les mises à jour, et aussi composer…) pour décider quelle version est compatible.
La recherche de ce forum sur le sujet semver donne quelques liens : bonne lecture !
Les plugins communautaires (du groupe git spip-contrib-extensions/* en particulier) commence à suivre aussi cette bonne pratique de plus en plus sérieusement.
Dans ce topic, le petit tableau de correspondance ci-dessous peut servir de base :
| version | etat |
|---|---|
| 0.X.Y | experimental |
| X.Y.0-dev | dev |
| X.Y.0-alpha* | test |
| X.Y.0-beta* | test |
| X.Y.0-RC* | test |
| X.Y.Z | stable |
Du coup, je pense ce serait bien de généraliser l’application de cette base aux plugins communautaires.
Autrement dit :
- avoir des versions
X.Y.0seulement quand ça devient « stable », avec unXdifférent de0, - faire des « up de Z » uniquement pour des correctifs, par exemple associés à une issue avec le label « bug »
- faire des « up de Y » lors d’ajout de nouveautés/améliorations qui ne cassent pas l’API, au sens large du terme, du plugin lui-même,
- faire des « up de X » uniquement pour des ajouts de nouveautés/améliorations qui cassent l’API du plugin lui-même,
- mettre à jour les deux attributs
versionetetaten conséquence (en attendant d’avoir un meilleur système dans le core) - ne pas craindre de sortir des
-alpha1,-alpha2,-beta1, avant de passer à l’état stable (et mettre l’état àtestà ce moment-là. - faire des branches de maintenances nommées
X.Y(voirspip/*à titre d’exemple) lorsqu’on souhaite maintenir des versions en parallèle - …
À titre d’exemple, un changement de bornes de compat’ spip mini est l’occasion de faire un up de X (saut de version majeure). Un changement de bornes de compat’ spip maxi devrait être associer à un up de Y
Celles et ceux qui ne souhaitent pas suivre cette bonne pratique peuvent bien évidement le faire, mais dans ce cas, il me semble qu’il serait bon de différencier les développements communautaires qui suivent semver de ceux qui ne la suivent pas, par exemple avec des groupes git.