Et pourtant, il est démontré que la version majeure de PHP la plus utilisée actuellement est la version 5.2.
À ma connaissance, le premier a avoir réalisé des statistiques sur le taux d'utilisation de PHP 5.3 et à les avoir rendues publiques a été Ilia Alshanetsky, qui a repris et enrichis le travail effectué auparavant par Damien Séguy.
Depuis, Pascal Martin s'y est également mis à deux reprises, et il y a quelques jours, j'ai découvert cette autre statistique.
Toutes ces sources confirment que malgré ses qualités, PHP 5.3 n'est utilisé en moyenne que par un peu plus de 20% des sites web mettant en œuvre PHP et que la grande majorité d'entres eux sont propulsés par PHP 5.2.
Or, PHP 5.2 n'est plus officiellement et activement supportée depuis sa version 5.2.14 qui date maintenant de juillet 2010, soit depuis pratiquement deux ans.
À mon sens, la meilleure raison pour migrer vers PHP 5.4 est donc de faire parti des 70% de développeurs (en faisant un très gros raccourcis) qui utilisent encore PHP 5.2, afin de pouvoir enfin profiter des avantages offerts par les dernières versions du langage et d'outils tels que Behat, atoum ou Symfony 2 qui nécessitent au minimum PHP 5.3.
Évidemment, la migration posera quelques problèmes, car la version 5.4 n'est pas compatible à 100% avec la version 5.3, qui n'était déjà pas elle-même compatible à 100% avec la version 5.2.
Cependant, c'est là le prix à payer pour avoir attendu si longtemps, et de plus, tout a été fait pour faciliter le processus de migration.
Une documentation a en effet été rédigée qui explique dans le détail les choses à prendre en compte pour migrer du code tout d'abord de PHP 5.2 à PHP 5.3, puis ensuite de PHP 5.3 à PHP 5.4, et cette dernière sera de plus prochainement disponible en français, si ce n'est pas déjà le cas au moment de la publication de ce billet.
Enfin, migrer ne veut pas forcément dire uniquement migrer du code, et il sera tout aussi pertinent de commencer un projet avec PHP 5.4 lorsqu'il sera disponible en version finale.
Avec une usine de code bien conçue qui met en œuvre des tests unitaires et fonctionnels dans un contexte d'intégration continue, et vu la qualité du code de PHP 5.4, le risque me semble en effet plus que raisonnable, même s'il n'est pas totalement nul.
De plus, en terme d'administration système, il existe des fournisseurs de paquets logiciels alternatifs comme Dotdeb qui permettent d'installer très rapidement PHP 5.3 sur un serveur, et il en sera de même pour PHP 5.4 lors de sa sortie.
Et si d'aventure le paquet logiciel ad hoc n'existe pas pour votre système d'exploitation, la compilation de PHP n'a vraiment rien de bien difficile, même si elle peut être fastidieuse, et de plus, elle est relativement bien documentée.
8 réactions
1 De Grunk - 24/02/2012, 15:52
Hélas , les màj sont souvent contrôlée par des sysadmin qui ont le syndrome du "ca-marche-donc-on-touche-pas" ou CP qui voient pas plus loin que le bout de leur nez et ne pense qu' au € dépensés à mettre à jour ...
Bref pas toujours facile de pouvoir être à jour
2 De Zef - 24/02/2012, 20:57
Le plus gros problème que l'on rencontre quand on a pas l'utilité d'un dédié c'est que les hébergeurs mutualisés traînent pour faire les mises à jours.
Espérons que quand ils se décideront de proposer une version plus récente ils sauteront la 5.3 pour passer à 5.4.
3 De moosh - 24/02/2012, 22:01
Je vais surprendre, surtout si des collègues me lisent parce que je me bat pour un passage à 5.3/5.4 depuis 2 ans.
Mais attention.
Le "ca-marche-donc-on-ne-touche-pas" n'est pas une maladie.
C'est un choix économique.
L'absence de support à long terme (je parle de 20-25ans) en informatique c'est de l’obsolescence programmée
En 40ans J'ai connu le super8, VHS, DVD, Blue ray et ca me fait déjà chier.
Mais qu'est-ce que ce ça aurait été si tous les 6à36 mois il avait fallu changer de technologie.
Oui ca coûte cher de mettre à jour. Très cher.
Et ca coûte à peine moins cher de penser plus loin. et en plus c'est pas ""you ain't gonna need it"" .
Bien sur ne pas vouloir évoluer peut vouloir dire qu'on se tire une balle dans le pied commercialement... quand on est sur un produit commercial.
Mais il ne faut pas cracher purement et simplement sur le "ca-marche-donc-on-ne-touche-pas"
Parfois un produit n'est rentable qu'en pensant court terme.
Je ne défend pas l'idée de stagner mais je comprend les choix (avec la part d'erreur que cela inclus) de la part des décideurs. J'accepte moins par contre, quand ils n'assument pas ce choix quand plus tard on dit "poubelle".
4 De Zéfling - 25/02/2012, 14:06
Le problème c'est qu'en informatique l'évolution a toujours été rapide. Il n'y a que les « domaines clos » qui peuvent se permettre de stagner : rien qui vienne de l'extérieur, donc le système est autonome. On voit encore des systèmes tourner sous Dos, voir plus vieux.
Sur internet, ce n’est absolument pas clos, et c'est donc s'exposer à des failles qui ne seront plus corrigées. On ne va pas demander à des équipes de veiller à la sécurité de 40 versions sur 20 ans. Ça serait économiquement impossible.
Le « on touche pas ça marche », j'ai récemment vu ce que ça peut donner : une société qui exploser un service dont la techno n'est plus supportée depuis 2003. Un vrai casse-tête pour trouver de l'aide ou de la doc. Ça marche toujours, sauf qu'on a perdu 2 mois pour faire quelque chose qui se fait initialement en 10 minutes.
Ça serait un peu comme vouloir lire un Laser Disc aujourd'hui, on galère pour trouver les outils et comment ramener son contenu vers les technologies qu'aujourd'hui.
Enfin, en temps que dév PHP, rester sous 5.2 serait un vrai problème pour moi, certaines améliorations de la 5.3 me sont devenues indispensable. Je n'ai pas encore touché la 5.4, mais risque que l'amélioration des perfs m’intéresse. Je ne sais pas si cela aura une incidence sur mon framework perso.
Sinon, rien à voir : le tout Unicode c'est prévu un jour ? Parce que je commence un peu en avoir marre de réécrire des fonctions pour pallier au problème.
5 De Bob l'éponge - 25/02/2012, 14:39
C'est vrai moosh pour quoi s'em***... avec toutes ces techno nouvelles alors qu'il suffit de faire ceci comme sur ma version de php 1.0 :
<!--include /text/header.html-->
<!--getenv HTTP_USER_AGENT-->
<!--ifsubstr $exec_result Mozilla-->
Hé, vous utilisez Netscape!<p>
<!--endif-->
<!--sql database select * from table where user='$username'-->
<!--ifless $numentries 1-->
Désolé, cette ligne n'existe pas<p>
<!--endif exit-->
Bienvenue <!--$user-->!<p>
Vous avez <!--$index:0--> crédits sur votre compte.<p>
pour avoir un code sale avec des traitements dans le html pour que tous soit difficilement maintenable et qu’on puisse facturer très cher la moindre évolution à nos clients.
Comment ? la programmation objet ? connait pas c'est quoi ce truc ?
mince php 2.0 est sorti je vais voir ce qu'il à ds le ventre.3...
...Désolé je me suis un peut emporté mais j'ai eu la même réaction l'année dernière quant mon prof de php nous suggérait d'utiliser le mot clef var au lieu de public comme si php5 n'était pas sorti.
6 De Pascal MARTIN - 25/02/2012, 18:55
L'idée de "sauter" PHP 5.3, pour passer directement de PHP 5.2 à 5.4 n'est définitivement pas mauvaise.
Après tout, plutôt que de faire une première migration vers 5.3 (avec les coûts / risques / difficultés que ça implique -- cf tous les sites / serveurs qui ne sont pas à jour), et de se rendre compte dans quelques mois que "et ben non, on n'est toujours pas à jour", pourquoi ne pas attendre quelques mois de plus, que 5.4 soit stabilisée (je connais pas mal de monde qui n'installeront pas une .0 sur un serveur de production, et attendront au moins une .2 ou supérieure, ne serait-ce que pour limiter les risques de bugs de la "première version") ?
OK, passer de 5.2 à 5.4 va peut-être demander un tout petit peu plus de travail que passer de 5.2 à 5.3 ; mais ça demandera forcément moins d'effort / temps que de passer de 5.2 à 5.3 puis à 5.4 six mois ou un ans après : tout l'effort de tests et de validation ne sera à faire qu'une seule fois, déjà -- et comme tu le soulignais, il sera facilité pour ceux d'entre nous qui ont la chance de travailler sur des applications couvertes par des tests automatisés.
Bien évidemment, je ne suggère pas de passer à PHP 5.4 en production aujourd'hui : comme tu l'as déjà rappelé plusieurs fois, on n'installe pas une version RC en production !
Par contre, au bout de 8 versions RC, il me semble tout à fait envisageable de l'installer sur les postes d'une parties des développeurs (ceux qui ont envie d'expérimenter, quitte à souffrir de quelques derniers bugs), ainsi que sur un serveur d'intégration continue.
Après, pour répondre en partie à moosh : oui, mettre à jour coûte cher, c'est évident.
Mais, d'une part, ça peut permettre aux développeurs d'utiliser des fonctionnalités (ou des outils / frameworks / bibliothèques qui en dépendent) qui les rendraient plus productifs, ou amélioreraient la qualité du code -- ce qui est investissement sur le long terme.
Mais aussi, mettre à jour est au bout d'un moment nécessaire ; ne serait-ce pour pour continuer à bénéficier de support et de mises à jour (même s'il ne s'agit que de correctifs de sécurité dans certains cas).
7 De moosh - 26/02/2012, 14:25
@Luc l'éponge
Vieux n'est pas sale.
Pour la petite histoire je me souviens que dans les années 90, quand sont apparus les 486 puis les pentiums, la nasa cherchait avidement des pièces de 386. Parce qu'il VOULAIT rester avec du vieux matos.
Pourquoi ? parce que refaire tous les tests sur du tout beau tout neuf aurait coûté bien trop cher.
Et c'est en ce sens que je m'oppose à l'expression cinglante "c'est vieux donc c'est moche" et que j'accepte le "ca-marche-donc-on-ne-touche-pas"
Ne pas maintenir et ne pas upgrader un code est plus économique que de le laisser comme ca.
Si j'avais codé une appli en 98 en C plutôt qu'un php, mon code serait encore valable aujourd'hui.
Ne me faite pas dire non plus ce que je n'ai pas dit je suis partisan de ne pas me retrouver dans cette situation.
Je développe en php, une techno qui évolue, et je défend le besoin de maintenir et upgrader mon code.
Mais pas parce que je veux rejeter le passé.
Je le veux pour être armé pour "rester dans la course".
@Pascal, "continuer à bénéficier de support et de mises à jour"
Mon premier coup de gueule fut avec l'alerte de sécurité qui faisait planter les serveurs 32 bits. (http://www.forum-webmaster.com/blog...)
J'avais dit qu'on l'avait échappé belle avec nos 64bits mais qu'on aurait été bec dans l'eau si on avait été obligé de passer à 5.3 sans avoir upgradé notre code.
"ça peut permettre aux développeurs d'utiliser des fonctionnalités..."
Finalement c'est cet argument là qui a gagné. Ces framework m'ont bien aidé à convaincre qu'il fallait passer à 5.3/5.4
(et la migration à été votée pour être travaillé ce semestre)
Pour ma part on bosse avec des vm et mon objectif de mars c'est de passer la moitié des sandbox en 5.3 et une en 5.4.
Et quand tout sera stabilisé sur les 5.3 je passe les 5.2 qui me restent en 5.4
8 De Fred Blanc - 27/02/2012, 14:03
@Zef :
Hello,
La bonne nouvelle c'est que certains hébergeurs sont en avance sur leur temps.
Exemple OVH propose via un setting dans le .htaccess d'activer PHP5.4 (évidemment pas en production, hein !).
Attention pour le moment c'est la RC1 qui est dispo, mais c'est déjà pas mal.
En connaissez vous d'autres ?
http://guide.ovh.com/php5chezovh
Pour ce qui est des sysadmin, typiquement chez nous c'est en terme de stabilité de socle technique que cela se joue. Ce qui explique pourquoi nous sommes toujours en 5.2. Mais dans certaines grosses structure, il faut faire preuve de patience et de persévérance. Le 5.3 pointe le bout de son nez, et on est pro actif sur php5.4. Préparation de démo fonctionnelle à l'appui.
En tout cas, merci à Fred pour l'excellente facture habituelle de ses articles.