Debian et peut être d’autres rebasculent certains patchs dans leur distributions. Ainsi, la plus petite version Debian maintenue (la 7) contient encore PHP 5.4
Certaines personnes sur l’IRC me disent que c’est encore tôt et que ça n’a pas de sens de forcer cette version alors que des PHP 5.3 traînent encore dans les campagnes. Ou qu’il faudrait quitte à changer basculer directement sur la dernière version maintenue de PHP (5.6).
Pour rappel SPIP 3.1 nécessite simplement PHP 5.1.
Entre autres choses dans PHP 5.4, c'est les écritures des tableaux possibles avec des crochets [], et l’arrivée des Traits.
Moi j'opterais au plus vite pour un 5.6.
Pour l'instant on maintient toujours la 3.1 donc je ne vois pas en quoi
cela gênerait pour la 3.2.
J'ai un spip 2.1 sur un hébergeur resté en php 5.3 "pour pas gêner les
vieux sites"
et ça ne me gêne pas que la 3.2 bascule en php 7.0 mini.
Passer à PHP 7.x serait pour le coup prématuré même si de plus en plus
d'hébergeurs offrent PHP 7.x dans leur offre.
Mais surtout, il faudrait que tous les dev revoient leur plugin pour tester
leur bon fonctionnement sur PHP 7.
Halte à la course à l'armement, je ne vois pas ce qui justifierait une compat mini à PHP 7.
Et puis pourquoi 7.0 et pas 7.1 ? Tout ça n'a pas de sens, surtout que le code de SPIP est bien loin d'utiliser tous les trucs objets et autres de PHP 7...
La compat, oui, mille fois oui, mais nécessiter, non.
Certaines personnes sur l’IRC me disent que c’est encore tôt et que ça n’a pas de sens de forcer cette version alors que des PHP 5.3 traînent encore dans les campagnes.
Je disais surtout que le sujet doit être discuté.
On a toujours dit que SPIP ne poussait pas à l'obsolescence et qu'il s'installait facilement sur des hébergements modestes, donc il me semble que c'est un sujet à décider en toute connaissance de cause.
Sur l'écosystème PHP, j'avançais l'argument des hébergements à la traine parce que c'est une réalité, par exemple CentOS (RedHat) en version 6 (soit la n-1) est encore sur PHP 5.3.3
La 5.3 n'est plus trop utilisée selon les stats basées sur les logs de packagist, donc des gens qui utilisent composer et qui sont à priori plutôt dans une utilisation moderne de PHP :
Mais selon des stats plus générales basées sur les classements Alexa :
Chez les voisins, Wordpress recommande PHP 7 mais supporte PHP 5.2.4+, avec un avertissement sur la fin de vie et les risques de sécu.
Drupal 7 : PHP 5.2.5 or higher (5.4 or higher recommended)
Drupal 8 : PHP 5.5.9 or higher (
Ou qu’il faudrait quitte à changer basculer directement sur la dernière version maintenue de PHP (5.6).
De ma part, c'était ironique
Si des fonctionnalités de PHP 5.6 sont indispensables à l'évolution du code, pourquoi pas, mais je n'ai pas l'impression qu'on en soit là.
Entre autres choses dans PHP 5.4, c'est les écritures des tableaux possibles avec des crochets , et l’arrivée des Traits.
Avez vous des avis là dessus ?
Ça ne me parait pas fondamental (dans le sens pas bloquant), mais bon, pourquoi pas.
La précédente décision sur la 5.3 date d'un an et demi (janvier 2016).
Certaines personnes sur l’IRC me disent que c’est encore tôt et que ça
n’a pas de sens de forcer cette version alors que des PHP 5.3 traînent
encore dans les campagnes.
Je disais surtout que le sujet doit être discuté.
On a toujours dit que SPIP ne poussait pas à l'obsolescence et qu'il
s'installait facilement sur des hébergements modestes, donc il me semble
que c'est un sujet à décider en toute connaissance de cause.
Sur l'écosystème PHP, j'avançais l'argument des hébergements à la traine
parce que c'est une réalité, par exemple CentOS (RedHat) en version 6
(soit la n-1) est encore sur PHP 5.3.3
Hello,
je suis assez d'accord sur le fait qu'on ne doit pas pousser à l'obsolescence et éviter de monter inutilement la version PHP requise.
Il me semblait que le passage à PHP 5.4 minima était défendable, mais si on a encore des cas concrets de distrib en 5.3, on peut décider d'y rester.
Il n'y a pas de gap fondamental en terme de fonctionnalités qu'on voudrait utiliser.
J’ai envoyé le changement https://core.spip.net/projects
/spip/repository/revisions/23619 pour forcer la version minimale de PHP à
la version 5.4
La plus petite version maintenue officiellement par PHP est la branche 5.6
(PHP: Supported Versions)
Debian et peut être d’autres rebasculent certains patchs dans leur
distributions. Ainsi, la plus petite version Debian maintenue (la 7)
contient encore PHP 5.4
Certaines personnes sur l’IRC me disent que c’est encore tôt et que ça n’a
pas de sens de forcer cette version alors que des PHP 5.3 traînent encore
dans les campagnes. Ou qu’il faudrait quitte à changer basculer directement
sur la dernière version maintenue de PHP (5.6).
Amha, PHP 5.4 est suffisant, pas la peine de demander plus.
Pour rappel SPIP 3.1 nécessite simplement PHP 5.1.
Entre autres choses dans PHP 5.4, c'est les écritures des tableaux
possibles avec des crochets , et l’arrivée des Traits.
Avez vous des avis là dessus ?
Moi j'opterais au plus vite pour un 5.6.
Pour l'instant on maintient toujours la 3.1 donc je ne vois pas en quoi
cela gênerait pour la 3.2.
Je ne suis pas pour forcer la 5.6. Dernièrement j'ai discuté avec un admin d'un site sous joomla qui justement me demandait de passer la version PHP d'un serveur de 5.5.38 à 5.6 car son site lui affichait un message alarmant à propos de sa version de PHP "obsolète et trouée", alors que la machine en question est sur une debian wheezy qui comme le disait marcimat, dispose par défaut de PHP 5.4.
Pour info, chez Infini, hébergeur associatif brestois qui propulse beaucoup de sites sous SPIP, on propose les versions suivantes :
- sur l'ancienne plateforme (qui fermera bientôt) : 4.3.10 et 5.2.17
- sur la nouvelle plateforme : 5.4.45 et bientôt 7.0 en plus
Un des objectif de cette génération était de rattraper le retard sur hvm.
En mon sens ce n'est pas un argument suffisant pour imposer cette
version minimum, vu notre code on devrait couvrir au plus large.
Par exemple si on disait qu'on casse une compatibilité juste pour
remplacer $toto = array() par $toto = [] serait me semble t il très
léger comme excuse.
La fonctionnalité trait est plus intéressant et plus défendable mais
comme le core de spip utilise assez peu l'objet cela semble en l'état
des choses léger.
Enfin le code actuel montre qu'il supporte assez bien un large
éventail de version jusqu'à 7, autant en profiter et au passage faire
de la pédagogie comme suggérer dans les messages précédent.
Hypothèse. Je gère un serveur hébergeant quelques dizaines de spip. Si j’en ai des vieux qui ne passent pas a php7 sans mise a jour et si le nouveau spip exige php7… Je suis un peu bloqué. Donc merci de ne pas rendre les choses plus compliquées : si on peut faire de la compatibilité faisons la.
Je suis moyennement d’accord avec ce raisonnement.
Si on doit prendre en compte les défauts de maintenance des autres, jamais on avancera. SPIP est à mon sens exemplaire en matière de mise à jours, passer de SPIP 1.9 à 3.1 est possible sans que ce ne soit trop complexe.
En informatique, de temps en temps, les choses casse parce qu’elles sont trop vieilles et il faut donc faire une mise à jour. Windows 98 est un exemple, plus aucun logiciel moderne ne support cette version.
Après, je suis d’accord qu’il faut rester raisonnable et être compatible avec les versions réellement utilisée de PHP tout en invitant fortement à être au goût du jour.
Une idée pourrait être d’être compatible PHP 5.4 mais de ne pas l’indiquer et ne garantir qu’une autre version (php 5.6 ?). D’ailleurs, je pense que c’est déjà un peu le cas si on installe certain plugin ?
Pour les version minimales de PHP, on peut faire le tour de versions anciennes mais encore tagguées comme stables.
Par exemple, sous Debian, la ‘oldoldstable’, jessie, propose php 5.4.45-0+deb7u2
CentOS 4 propose une version de PHP > 5.4
php5.4.0 est la dernière version a être distribuée pour windows XP et windows 2003…
Existe-t-il une raison sérieuse de ne pas considérer PHP 5.4.x comme étant une version minimale des futures installations de SPIP, à avoir sur son serveur, à moins d’utiliser des OS super archaïques ?
