Hop,
Je ne pense pas que le saut de version majeure soit nécessaire quand un plugin abandonne la compatibilité avec une version de SPIP plus maintenue. Amha, si le plugin en question ne casse rien dans ses APIs ou dans ses usages, il n’y a pas de raison de faire un saut de X, un saut de Y devrait suffire. Le simple fait d’indiquer que le plugin n’est plus compatible avec SPIP 4.0 par exemple ne cassera rien pour les sites en 4.0, il ne pourront juste plus faire de mise à jour vers ta version Y+1.
À titre d’exemple perso, j’ai porté la distribution geodiversite de SPIP 3.2 vers SPIP 4 il y a 10 mois. Cela a nécessite pas mal de travail et cassait des choses, geodiversite est donc passé de la version 3.0.0 à la 4.0.0. Un mois plus tard, je l’ai porté vers SPIP 4.1, cela a demandé bien moins de travail et cette fois rien n’était cassé, donc j’ai opté pour une version 4.1.0 (qui garde la compat SPIP 4.0) pour marquer le coup.
Ref v4 compat SPIP 4 · Issue #33 · geodiversite/geodiversite · GitHub & Compat SPIP 4.1 · Issue #37 · geodiversite/geodiversite · GitHub
Autre cas, autre choix, quand j’ai décidé de porter GIS pour SPIP 4.2, j’ai décidé de ne supporter que les versions maintenues de SPIP (donc uniquement la 4.1 et la 4.2). Ça aurait pu se faire dans la branche 4, qui était compatible de SPIP 3.0 à SPIP 4.1, en retirant le support des versions < 4.1, mais je souhaitais aussi profiter de l’occasion pour faire du ménage dans des fonctions dépréciées du plugin et aussi retirer du code plus maintenu depuis des années. Et ça permet en plus de garder la branche 4 au chaud pour les gens qui utilisent SPIP 3.2 et souhaiteraient corriger des bugs dans GIS uniquement pour cette version.
Ref #53 - Nouvelle branche compatible SPIP 4 mini - gis - SPIP on GIT & #54 - refonte v5 - gis - SPIP on GIT
En tout cas, je pense que c’est vraiment bénéfique de faire le choix de ne maintenir un plugin que pour les versions maintenues de SPIP. Ça facilite grandement le passage d’une version Y à une Y+1 de SPIP (depuis la version 4), ce qui permet d’assurer la pérennité du plugin à moindre temps (d’autres parlerait de coût). Ça permet aussi d’éviter les prises de têtes avec les différentes versions de PHP supportées, le moindre array déclaré en [] pète la compat avec SPIP < 3.2 cf #28 - codings standards SCS1 - gis - SPIP on GIT
Voilà ce que j’en pense, mais peut-être que je suis à côté de la plaque n’étant pas un expert du semver 
