La date de sortie de la version stable de PHP 7 pourrait être repoussée
Pour améliorer la qualité du code, qu'en pensez-vous ?

Le , par Olivier Famien

21PARTAGES

8  0 
Le 29 octobre dernier, PHP 7 RC 6 a été publié. Cette nouvelle version constitue la 11e du genre parmi la série des préversions publiées jusqu’alors. Dans cette préversion, 10 nouveaux bogues ont été corrigés.

Au menu des erreurs corrigées, l’on notait, entres autres, qu’une exception déclenchée lors d’une comparaison identique engendrait une boucle infinie. Le gestionnaire d’exceptions ne fonctionnait pas comme prévu. Un débordement de la mémoire de la pile a été détecté dans le parser du langage Zend. Le client SOAP générait Segfault. Un défaut de segmentation a été observé dans le client SOAP. Une sérialisation incorrecte de l’objet ArrayObject pointait du nez si la fonction unset était appelée dans la fonction serialize().


Tous ces éléments et bien d’autres encore ayant été corrigés dans cette 6e Release Candidate de PHP7, la prochaine étape selon le planning devrait être la sortie de la version finale le 12 novembre.

Toutefois, Anatol Belski, développeur du noyau de PHP et gestionnaire de la publication de PHP 7.0, a annoncé depuis peu « qu’après les dernières évaluations dans le cercle des gestions de versions précédant l’orientation vers les préparations pour la version 7.0 RTM, nous sommes parvenus à la conclusion que l’état actuel ne parait pas raisonnable pour être utilisé comme la version finale ».

« Les versions Release Candidate avant la version RC6 apparaissaient acceptables, ce qui nous a donné des motifs pour annoncer la date de la version RTM programmée pour le 12 novembre comme finale. À partir de la perspective d’aujourd’hui, la plupart des problèmes découverts et corrigés depuis la version RC6 sont encore mineurs en raison de leurs caractéristiques – 7 crashes (le bogue #70805 plutôt critique) et 3 régressions de fonctionnalité. Toutefois, étant donné la quantité et la combinaison de tous ceux-ci, l’état est à notre avis impropre pour le démarrage du cycle de vie de la prochaine version majeure ».

« Ainsi, la reprise du cycle des préversions semble de notre point de vue la chose appropriée à faire pour l’instant. D’où cette adresse pour informer la communauté sur l’intention et recueillir les avis. PHP 7 est toujours dans la dernière ligne droite et est très proche de l’achèvement. La prochaine version RC sera peut-être bien la dernière. Bien que nous préférions nous assurer d’abord de la qualité autant de fois que possible au lieu de fournir un mauvais service aux consommateurs ».

À la lumière de cette annonce, il ne serait pas incongru de conclure que la date du 12 novembre pour la sortie de la version RTM de PHP 7 sera repoussée afin que le produit une fois sorti ne souffre aucunement de défaut de qualité.

Certaines personnes trouvent cela raisonnable de repousser cette date si la qualité actuelle n’est pas optimale pour l’instant. Et d’ajouter que ce serait nul de publier une chose qui une fois sortie serait remplie de bogues.

D’autres par contre ne trouvent aucune objection à ce que la date initiale soit respectée en dépit de la qualité du produit qui pourrait être reprochable. Des corrections d’erreurs pourraient suivre à mesure que les découvertes de bogues seront faites, soutiennent ces derniers.

Source : PHP News

Et vous ?

Que pensez-vous de cette annonce ?

Que pensez-vous de ce report probable ?

Voir aussi

Forum langage PHP

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de ABCIWEB
Expert éminent https://www.developpez.com
Le 10/11/2015 à 3:34
Salut,

Je suis de l'avis du premier groupe qui préfère retarder la sortie. Pourquoi sortir une version alors que des bugs récents ont été découverts ? Même corrigés mieux vaut prendre le temps de vérifier qu'ils n'ont pas d'autres impacts, et que les corrections proposées soient testées dans toutes les combinaisons possibles.

En plus les dernières versions de php depuis 5.3 ont notablement amélioré les performances, ce qui à mon avis permet d'attendre encore quelques semaines dans de bonnes conditions sans trop d'impatience.

Et puis php commence à perdre son aspect amateur, qui en fait n'était pas dû au langage lui-même mais à la grande diversité de niveau des utilisateurs puisqu'étant le langage le plus accessible c'est aussi celui qui attire le plus de débutants.

L'équipe php a augmenté les contrôles minimum pour récupérer des variables, fourni un bon cadre pour le développement objet, des nouvelles classes bien pratiques, des gains en performances pour les dernières versions etc. sans oublier les nombreux framework construits autour qui se sont eux aussi améliorés. De quoi satisfaire le plus grand nombre.

Pourquoi prendre le risque de contrarier cette montée globale qualitative en sortant une version buggée qui cette fois-ci ramènerait le problème non plus à la maladresse de certains débutants mais au moteur du langage lui-même. Ce serait une bien mauvaise publicité
Tout ça pour respecter une date ? Nan franchement, sauf à donner le bâton pour se faire battre, quel intérêt ?
Avatar de RyzenOC
Inactif https://www.developpez.com
Le 10/11/2015 à 8:44
J'ai tester la dernière RC est je n'ai pas découvert bugs.

Mais je préfere avoir un produit en retard mais de qualité, je suis plutôt pour un report.
Avatar de Zefling
Membre expert https://www.developpez.com
Le 10/11/2015 à 9:01
Je suis impatient de voir cette version sortir, mais je préférais que ça soit une vrai stable. Et on n'est plus à quelques jours/semaines près, depuis l'échec de la 6, on a appris à être patient.
Avatar de Grimly
Membre averti https://www.developpez.com
Le 10/11/2015 à 10:40
Il vaut mieux attendre un bon produit qu'un ramassis de bugs.

A la vue des bugs je pense que c'est justifié. Même si des fonctions avancées de zend sont utilisés, je n'aimerais pas tomber sur un segfault alors que mon application n'a pas changé.

Pour les impatients, il y a toujours les RC.
Avatar de Pierre Louis Chevalier
Expert éminent sénior https://www.developpez.com
Le 10/11/2015 à 23:11
A ce propos c'est très impressionant le score PHP sur : Quel est votre langage serveur préféré pour le Web en 2015 ?

Ca fait un moment que pierre paul jacques essaient de lancer le nouveau langage révolutionnaire pour le web et au final c'est les bons vieux PHP et Javascript qui restent au top
Avatar de koyosama
Membre éprouvé https://www.developpez.com
Le 10/11/2015 à 23:43
GTA IV ou Assassin's Creed hum ?!?

Mouais, la patience est une qualite comme on dit ^^.
Avatar de air-dex
Membre émérite https://www.developpez.com
Le 11/11/2015 à 0:58
PHP 7 doit être la version de PHP qui le consacrera. Qu'ils reportent sa sortie s'ils le jugent nécessaire afin de ne pas transformer cette consécration en braconnage d'éléPHPants.
Avatar de CoderInTheDark
Membre expérimenté https://www.developpez.com
Le 11/11/2015 à 9:44
Je penche un peu vers le deuxième groupe, je me sens un peu seul.
Je vais me faire lyncher.

Mais voila, il faudra bien se lancer un jour.
De toute façon des bugs, on trouvera toujours

Même si on me dit que il s'agit d'une version stable.
Je pense pas l'utiliser en production avant un moment.Je penche un peu vers le deuxième groupe, je me sens un peu seul.
Je vais me faire lyncher.

Mais voilà, il faudra bien se lancer un jour.
De toute façon des bugs, on en trouvera toujours.
Mais ceux énoncés, sont quand même graves.
Repousser cette fois d’accord.
Mais depuis le temps qu’on l’attend, il faudrait qu’elle arrive avant la fin de l’année.In ne faudrait pas nous refaire le coup encore une fois.

De toute façon, je ne pense pas l'utiliser en production avant un moment.
Avatar de SurferIX
Membre chevronné https://www.developpez.com
Le 11/11/2015 à 10:15
Citation Envoyé par Artemus24 Voir le message
Je n'ai jamais compris que l'on ne maintienne pas un code, même vieux de plus de 12 ans.
Dois-je comprendre que le propriétaire de ce code, ne sait pas comment le faire évoluer car il n'a pas la connaissance ?
Ou bien, tant que l'hébergeur offre encore une version php4, il n'est pas nécessaire de faire cette migration ?
A moins que tout cela ne soit qu'une question de budget.
Ouf. Merci pour ta dernière ligne, j'ai cru à un moment donné que tu n'avais jamais travaillé en entreprise !

Citation Envoyé par Artemus24 Voir le message
Il arrivera un moment où la migration coûtera plus cher que la refonte de l'application.
Donc toujours remettre au lendemain ce que l'on peut faire aujourd'hui est une très mauvaise stratégie, surtout en terme de coût.
Ah eh bien au vu de cette remarque : tu as travaillé en entreprise, mais pas encore assez longtemps !
Aujourd'hui c'est du consommable qu'on vend, le code y compris, et Php permet (malheureusement) de faire cela : du code rapide, difficile à maintenir, mais jetable.
Donc il arrive toujours un moment où la ré-écriture coûte moins cher que la maintenance, mais ce moment n'est jamais "clair" et c'est toujours dur de convaincre un patron, voire pire : une équipe d'anciens qui ne veut pas changer.

---------------------------------------------------------------------
Dans tous les cas : maintenir du code, le faire évoluer pour proposer au clients exactement les mêmes choses, c'est juste impensable en termes de budget, car il n'y a rien de nouveau à vendre.
Donc du code qui n'évolue pas, c'est compréhensible, point à la ligne.
Après, mon application de plus de 32000 lignes de codes est passée de Php 4 à Php 5 sans aucune modification. Absolument aucune . Je croyais même que je m'étais trompé et que j'étais pas sous Php5. Donc là aussi ce n'est pas qu'une question de Php, c'est aussi une question de développeurs : pour un salaire de débutant on a du code de débutant, c'est clair.

Mais arrêtez de critiquer les développeurs qui ne font pas évoluer leur code. Du point de vue de l'entreprise, c'est compréhensible, et normal, end of story.

Citation Envoyé par sazearte Voir le message
Depuis que je code uniquement en Python et que j'ai abandonné le C, je vois la vie en rose
Je dis pareil mais avec Php : depuis que je code uniquement en Python je vois la vie en rose

Citation Envoyé par stailer Voir le message
@Artemus et @Tsilefy : pfffouuu... que répondre. Y aurait pas un dév C# par là , je sais plus quoi leur dire....
C# c'est comme C++ : on peut absolument tout faire, et tout faire proprement. C'est génial. Héritage, héritage multiples, promise, typage fort, statiques, privées, publiques, etc etc, bref, la totale du kamasutra et plus.
Seul hic : on peut absolument tout faire, et tout faire proprement... si on a tous la même façon de fonctionner. Je peux te montrer des codes source C++ qui ressemblent presque à deux langages différents ! Bref.

L'autre chose qui me fait sourire c'est Php : tout le monde en a tellement marre du code pourri que Php permet de faire (dernier en date qui m'a fait perdre 2 heures. Pour résumer façon directe, essayez : php -r '$b = 15; $a = "45".$b=15;' aucune erreur, aucun warning, le code fait juste n'importe quoi (enfin c'est logique mais façon Php)) qu'on commence à essayer le typage fort... vraiment n'importe quoi, on est en train d'enlever ce pour quoi Php est né...

Bref, Python est resté sur le duck typing, qui est à la fois du typage fort et faible : une variable est typée lorsqu'elle est initialisée. Ici aussi je vends pas du Python, je parle d'une pratique qui a plus d'une trentaine d'années, et qui tourne très bien, donc autant que les autres s'en inspirent.... allez j'arrête de perdre du temps avec Php, j'en ai déjà perdu assez depuis 12 ans...
Avatar de Artemus24
Expert éminent sénior https://www.developpez.com
Le 12/11/2015 à 8:54
Salut SurferIX.

Citation Envoyé par SurferIX
Ouf. Merci pour ta dernière ligne, j'ai cru à un moment donné que tu n'avais jamais travaillé en entreprise !
Tu es du genre à croire que tu es le seul à travaillé dans le monde de l'informatique. Et bien non, il n'y a pas que le web !
Je te confirme que j'ai fait toute ma carrière dans les SSII, dans le milieu bancaire. Donc je sais de quoi je parle.
Sauf que j'ai fait du gros système BULL et IBM et non du web.

Croyez-vous que tout est une question de budget ? Non !
Le fond du problème concerne aussi la compétence pour venir mettre son nez dans un vieux machin dont plus personne ne comprend rien.

Citation Envoyé par SurferIX
Aujourd'hui c'est du consommable qu'on vend, le code y compris, et Php permet (malheureusement) de faire cela : du code rapide, difficile à maintenir, mais jetable.
Je comprends surtout que c'est votre façon de travailler dans le monde du web.
Aucune méthodologie, que du bidouillage et après vous vous étonnez le manque de rigueur dans vos développements.
Tout ce que vous savez faire, c'est du copier/coller.

Vous avez des clients qui vous demandes un travail, et vous êtes en mesure d'accepter ou de refuser leur proposition.
Vous faites que du neuf, et jamais de la maintenance car cela ne vous intéresse pas.

Dans le monde bancaire, on fait à plus de 80% de la maintenance et parfois dans des langages que l'on doit apprendre sur le tas.
Et je ne parle même pas des contraintes imposés par le client (la banque) pour développer, faire les tests, la mise en production et le versionnage.

Citation Envoyé par SurferIX
Donc il arrive toujours un moment où la ré-écriture coûte moins cher que la maintenance, mais ce moment n'est jamais "clair" et c'est toujours dur de convaincre un patron, voire pire : une équipe d'anciens qui ne veut pas changer.
C'est faux ce que vous dites ! En réécrivant une application, vous risquez d'introduire de nouveaux bugs alors que la vieille application à déjà été testé maintes fois.
Vous ne tenez pas compte du temps nécessaire pour refaire une batterie de tests avant de la mettre en production. C'est cela qui coute cher !
Le but d'une maintenance est de corriger les bugs que l'on rencontre. Donc en terme de bugs, un existant est bien plus efficace qu'une refonte totale d'une application.

La nécessité de tout réécrire vient quand la question de la performance est soulevée, ou encore quand on change de système d'exploitation ou quand elle ne correspond plus à ce que l'on attend d'elle.
J'ai en tête la migration de Bull vers IBM, en gros système, car en changeant de base de données (IDS II vers DB2), la performance était désastreuse.
Et pourtant, le langage commun entre ces deux système d'exploitation (BULL et IBM ) est bien le cobol.
Sauf que il y a de grosses différences dans la façon de représenter les données et de les gérer.
Passez d'une base de type réseau à une base de type relationnel modifie grandement la façon d'accéder aux données et par voie de conséquence les temps d'accès.

Oui, mais voilà, vous ne connaissez pas ce genre de problème car vous travaillez toujours avec les mêmes langages, dans le même environnement.
Et comme vous dites, vous n'avez aucune contrainte car vous faites du jetable.
C'est plutôt à moi d'émettre des doutes sur votre compétence professionnel.

@+
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web