Disons-le immédiatement au risque de décevoir, les décisions prisent n'ont pas été nombreuses, mais énormément de discussions sont en cours.
Ainsi, le nom de la prochaine version n'est pas encore clairement défini. PHP 5.4 ? PHP 6 ? PHP 7 ? Un consensus n'a pas pu être trouvé.
Après pas mal de tergiversations, un nouveau trunk a été créé à partir de la branche PHP_5_3 pour accueillir les futurs développements, et le nom de version qui lui a été associé est 5.3.99-dev.
Cependant, certain trouve que les règles régissant le développement de la prochaine version ne sont pas assez clairement définies, et d'autres ont demandé une feuille de route plus claire, avec une planification précise et un cycle de mise à jour plus rapide, vu que beaucoup de nouvelles fonctionnalités étaient prêtes.
Dieu Rasmus a alors réagit, fidèle à son esprit utlra pragmatique, en disant clairement que PHP devait avancer, et que la chose absolument nécessaire pour cela était d'avoir un trunk permettant de se mettre au travail.
Il a également rappelé que le développement de PHP n'était plus marrant depuis très longtemps, qu'il pensait que c'était une des raisons de l'échec de la branche PHP6, qu'en conséquence il souhaitait que cela change afin que les développeurs et les contributeurs retrouve du plaisir à développer le langage et fasse donc avancer les choses, et qu'il serait toujours temps de définir les choses plus clairement une fois cela fait.
Il a ensuite continué en disant que personne ne pouvait dire qu'une fonctionnalité étaient prête à l'intégration tant qu'elle n'avait pas été incluse dans le trunk et qu'elle ne passait pas les tests avec succès, et que pour les autres, il était nécessaire de faire le ménage dans les RFC avant d'en faire quoique ce soit.
Amen !
Autre point positif, dans le cours de cette discussion, il a été évoqué le fait que la prochaine version de PHP dispose de deux coordinateurs, encore inconnus à ce jour même si des noms circulent, vu que l'expérience a très bien fonctionné pour la version 5.3.
Par ailleurs, suite à la remarque de Rasmus au sujet des RFC, plusieurs discussions ont débuté, notamment à propos des traits
, de la bufferisation, de l'intégration de DTrace
, de l'interface FPM
, d'une amélioration des performances via une optimisation du code du modèle objet (de 10 à 25% tout de même dans certain cas précis), ainsi que de l'intégration d'un nouvel algorithme de haschage.
Les discussions sont plus ou moins avancées et des choses plus ou moins sympatiques en sont ressorties, mais rien n'est encore tranché.
Il a également été évoqué l'idée de supprimer de la prochaine version les fonctionnalités de merde qui devaient être supprimées dans PHP6, mais là encore, rien n'a été tranché et des décisions seront prisent au cas par cas.
Par contre, il a été décidé de conserver les rapports de bug concernant PHP6, puisqu'une partie du code de ce dernier sera certainement utilisé dans la prochaine version et qu'il serait dommage de se priver de ces informations en les détruisant.
Les deux grands abscents des discussions sont à mon sens Unicode et les Closures.
Concernant le support d'Unicode, à ma connaissance, il n'y a encore aucune RFC de disponible et il n'est même pas certain qu'il sera intégré dans la prochaine version majeure du langage.
Plusieurs pistes ont été évoquées par Rasmus et d'autres, comme l'utilisation plus générale de mbstring
, intl
, et une classe String
, mais cela n'a pas été plus loin pour le moment.
Concernant les Closures, aucune discussion n'a débuté à leur sujet pour le moment, mais je sais par d'autres sources que des choses sont prêtes ou en cours à ce niveau et j'ai donc bon espoir que des discussions débutent à leur sujet rapidement.
Au final, les choses se mettent en place trop très doucement, et à la lecture des discussions, il est très palpable que les personnes impliquées cherchent une méthode de travail qui permettrait de ne pas retomber dans les mêmes ornières que celles rencontrées lors du développement de la branche PHP6 et que rien n'est définitivement tranché.
Cependant, des fonctionnalités intéressantes sont en cours de discussion, et même si Unicode n'en fait pas parti, c'est prometteur.
Je vous donne donc rendez-vous dans quelques temps pour un nouveau point sur ce que sera, ou pas, la prochaine version majeure de PHP.
9 réactions
1 De Laurentj - 26/03/2010, 11:54
>Les deux grands abscents des discussions sont à mon sens Unicode et les Closures.
Les closures ? c'est pas déjà dans PHP 5.3 ? Tu ne confond pas avec les traits ?
2 De Laurentj - 26/03/2010, 12:05
>Il a également rappelé que le développement de PHP n'était plus marrant depuis très longtemps,
Bah ouai, mais bon, la faute à une gestion des tickets/bugs plutôt désastreuse vis à vis de la communauté, qui ne donne absolument pas envie de contribuer (parce que bon, les tickets fermés avec sans plus d'explication qu'un commentaire automatique, sans reference au numero de revision quand il y en a un, etc...).
Bref, il faudrait déjà qu'ils passent à un mode de dév plus souple, (passer à git/mercurial), à un vrai bug tracker plutôt qu'à un outil maison très pauvre en fonctionnalités (à croire qu'il ne sert à rien et fait seulement parti du décors, histoire de..) et à un accueil un peu plus chaleureux pour les contributeurs et les rapporteurs de bug. Et que les core-developers changent un peu leur attitude, et arrêtent de prendre les nouveaux venus comme des moins que rien.
Leur modèle de développement est à l'image du langage : mal vieillissant.
3 De mageekguy - 26/03/2010, 12:06
@Laurentj : Non je ne confond pas. Les closures de PHP 5.3 sont intéressantes mais très clairement limitées, et un certain nombre de patchs sont dans les tuyaux pour les faire évoluer et leur donner plus de souplesse et de puissance.
4 De desfrenes - 26/03/2010, 15:48
"Les closures de PHP 5.3 sont intéressantes mais très clairement limitées"
marrant comme on peut remplacer facilement des mots dans la phrase:
"Les namepaces de PHP 5.3 sont intéressants mais très clairement limités"
5 De mageekguy - 26/03/2010, 16:03
@desfrenes :
Il faut que tu m'expliques, là... parce que je ne vois pas trop ce que tu reproches au espace de nommage.
6 De desfrenes - 26/03/2010, 17:21
T'as raison, c'est pas seulement les namespaces le pbm, mais plutôt l'absence de modules, qui forcerait les convention de nommage des fichiers. Je parle pas du \ ... ça fait un signe de plus avec -> et :: là où beaucoup n'utilisent que le .
ça a l'avantage d'exister mais ça a quand même un petit goût d'inachevé.
7 De metagoto - 27/03/2010, 02:29
Passer à un VCS décentralisé est un sujet récurent. Ces discussions n'aboutissent jamais à rien car les membres les plus influents ne se prononcent pas. On reste avec SVN par défaut. Le passage de CVS à SVN étant somme toute récent, je comprends que certains n'aient pas envie de réorganiser leurs tools et méthodes de travail. Quelque part, ils payent l'erreur d'être passé à SVN. Je n'ai jamais compris ce choix.
A mon sens, le plus gros problème du développement de php est son manque de docs et références sur l'architecture et les mécanismes internes du ZE. Seule une poignée d'initiés ont en tête tout le fonctionnement de php. Cette fraction des core developers a tendance, comme le fait remarquer @Laurentj, à prendre les nouveaux venus comme des moins que rien. Le comble, c'est que c'est justifié. Une conséquence du brouillard dans lequel php évolue.
8 De uberVU - social comments - 06/04/2010, 18:32
Social comments and analytics for this post
This post was mentioned on Twitter by mageekguy: Des news de PHP next version : http://blog.mageekbox.net/?post/2010/03/25/Mort-de-PHP6-10-jours...
9 De Julien Breux - 07/04/2010, 13:45
@metagoto : "A mon sens, le plus gros problème du développement de php est son manque de docs et références sur l'architecture et les mécanismes internes du ZE" Je suis entièrement d'accord avec ça !