Branches et compatibilité : bonnes pratiques

Je tombe sur le plugin Vérifier et le changement de bornes de compatibilités qui a été fait à la hussarde par up de y + il est temps d'arret de supporter une version de SPIP qui n'est plus supportée, fonctionnant sur des versions de PHP qui ne sont plus supportées · 3f2a509e9d - verifier - SPIP on GIT

Autant étendre l’intervalle de compatibilité avec SPIP sur une branche existante ne pose pas de problème particulier (sauf à bien être certain de pas avoir à revenir en arrière), autant réduire l’intervalle de compatibilité en enlevant le support de versions SPIP ne doit pas se faire à la légère.

Pour illustrer, dans le cas précis, si on doit faire un fix de sécurité ou même a minima un bugfix parcequ’un vieux site continue de tourner sur une veille version du plugin, on est totalement coincé.

La bonne pratique, quand on veut abandonner le support de vieilles versions de SPIP est toujours de faire une nouvelle branche.
Ici donc, il aurait faire une branche de maintenance pour la version v1 du plugin, et passer le master en branche v2. Au passage, cela permet également d’être plus ambitieux et de monter la version mini de SPIP à 3.2 par exemple, laissant le support des plus vieux SPIP à la branche de maintenance si besoin et c’est ce que j’ai fait sur le plugin vérifier ce jour.

1 « J'aime »

on avait hésité. On se disait qu’un up de x juste parce qu’on voulait abandonner un support était d’un truc plus supporté était un peu too much.

Cela étant, avec le recul et tes remarques, je vois qu’effectivement ce n’était pas la bonne pratique.

Pour avoir galéré à devoir forker des plugins qui ont eu leur version mini passée sur 3.0 alors qu’il me restait des SPIP en 2.* avec plusieurs mois avant de pouvoir êtres mis à jour, je plussoie à la proposition de bonne pratique :slight_smile: