Si on suit semver, le changement de PHP sur un Y ne devrait pouvoir n’être que augmenté (la version Y+1 gère plus de version de PHP, mais pas moins). Donc ça ne change rien aux plugins, et ça ne change rien aux sites en place avec la version précédente de PHP déjà gérée. Normalement seules les versions X+1 devraient retirer des compatibilités PHP trop anciennes.
Oui, tout à fait, mais un plugin testé compatible jusqu’à PHP 8.2 pourrait avoir des incompatibilités (warning) avec PHP 8.3, non ?
Je ne sais pas à qui/quoi tu réponds, mais je le répète 4.2 et 4.3 sont compats PHP 8.3 à ce jour (et peut-être qu’il en sera de même pour la 4.3 et la 4.4 dans le futur).
Ah oui, c’est vrai, la compat de la 4.2 avec PHP 8.3 a été introduite en z.
Mais les plugins testés compatibles 4.2 l’ont été pour l’essentiel avec PHP 8.2 max.
Donc, j’attire juste l’attention que changer les bornes de compatibilités de 4+ avec PHP n’est pas forcément anodin en termes de compatibilité des plugins.
Dois-je rappeler l’objet du fil ici présent ? ^^
Après relecture, il semble que la majorité des personnes qui se sont exprimées ici sont d’accord avec l’idée de passer tous les plugins compatibles 4.2 en compatibles 4.3 avec un saut de version patch ou mineure + push du tag pour diffuser tout ça.
Est-ce qu’on valide ça rapidement histoire que les quelques personnes qui souhaitent installer un SPIP 4.3 dans moins de deux semaines aient tous les plugins compats 4.2 à dispo pour leurs sites ? Faut-il qu’on lance un sondage pour trancher ?
Je rejoins cette remarque, amha si on lance une action en masse, autant qu’elles serve sur le long terme plutôt que de la rejouer tous les 6 mois (pour rappel la version 4.4 est prévue 6 mois après la sortie de la 4.3 cf Versions maintenues - SPIP).
On peut aussi faire un sondage avec les trois options : rien ne bouge / compat 4.3/ compat 4.*
1 « J'aime »
A priori, même faire un sondage n’emballe pas … 
La branche 4.4 a été créée, depuis la 4.3 et bien qu’il y ait une certaine défiance, il y a tout de même un engagement a ne pas casser la compatibilité ascendante (tout ce qui marche pour 4.2 doit marcher pour 4.3 et 4.4), c’est exactement pour ça qu’on ne parle que de la borne max des plugins.
Dit autrement :
- si une nouveauté dans l’API technique de SPIP apparaît dans le futur (désormais dans la 4.4) elle ne cassera pas la compat avec l’API de SPIP4.2
- le corollaire, c’est qu’un plugin qui cherche à tirer avantage de cette nouveauté DEVRA avoir sa borne MIN ajustée, mais sera compat’ 4.* max
- si une nouveauté dans l’API technique de SPIP apparaît, MAIS qu’elle casse la compat avec l’API de SPIP4.2, elle ne sera intégrée que dans SPIP5
ça, ça ne s’automatise pas : Soit on fait un choix tout de suite et on peut re-envisager un traitement de masse, soit c’est du cas par cas et ça revient à laisser les « mainteneureuses » faire l’entièreté du boulot (comme l’a commencé @maieul ) (et comptez-vous … vous êtes moins de 30 personnes pour 500+ plugins)
1 « J'aime »
ça me va très bien de pas devoir mettre à jour les bornes de compat de 20 plugins
1 « J'aime »
Je suis favorable à la déclaration de compat 4.*
Ça évitera de refaire le même traitement dans 6 mois.
Y’a un sondage quelque part ?
Et voila le sondage avec les trois options : rien ne bouge / compat 4.3/ compat 4.*
- rien ne bouge
- compat 4.3
- compat 4.*
0 votant
1 « J'aime »
autant éviter les opérations répétitives : de toute façon on a déjà des pétouilles de compatibilité ponctuelles lors des montées de versions (j’avoue que pour les plugins que j’utilise/maintient j’ai tendance à faire la modification du paquet.xml après des tests minimalistes et compter sur les retours utilisateurs pour les cas d’usages compliqués…)
1 « J'aime »
Bien, bien, je viens de voter pour 4.* finalement du coup (on ne voit pas qui a voté et quoi apparemment ?)
Merci !
Bah c’est bien chouette, ça permet de basculer rapidement des sites en 4.3-beta pour tester sans utiliser la constante spécifique…
2 « J'aime »