Elle nous apprend en effet que la première release candidate est prévue pour septembre 2011, et qu'elle devrait être suivie par d'autres toutes les deux semaines jusqu'à ce que la stabilité du langage soit jugée satisfaisante.

D'ici là, nous devrions pouvoir nous mettre sous la dent fin juillet une autre version alpha, suivie par une beta fin août.

Le calendrier est donc clair, mais j'éviterais de trop m'y fier, car par le passé, de tels jalons ont déjà été posés et n'ont jamais été atteints.

La situation d'aujourd'hui est cependant très différente de celle de l'époque, car beaucoup de problèmes ont été résolus depuis, notamment au niveau de la gestion du projet.

La RFC relative au processus de release du langage est en cours de validation, et les premiers votes semblent indiquer un consensus majeur autour de cette question, même si le nombre de votants est relativement faible pour le moment et que des contributeurs historiques ne sont pas encore exprimés.

J'ai donc bon espoir que le calendrier soit finalement respecté, même si je prédis quelques difficultés d'ici la sortie de la version finale, d'autant qu'elle est sous la responsabilité des release managers Stanislav Malyshev, aka stas, et David Soria Parra, aka dsp, qui sont plus actifs sur internals@ que sur le trunk.

Outre le calendrier, la feuille de route nous apprend également ce qu'il reste à faire au niveau technique et fonctionnel d'ici septembre 2011.

Elle nous apprend notamment que faire passer un maximum de tests unitaires au vert reste une préoccupation forte depuis la remarque de Dieu Rasmus Lerdorf à ce sujet.

La gestion des traits, et plus particulièrement de leur interaction avec l'introspection, est aussi au menu des contributeurs.

Ce point semble d'ailleurs être relativement délicat, car les choses ne semblent pas avoir évoluées depuis ma discussion à ce sujet avec Stephan Maar, l'auteur de l'implémentation des traits dans PHP, lors du rendez-vous AFUP correspondant.

Cela confirme cependant que les traits feront bien partis de la version 5.4, sauf problème majeur.

Du nettoyage est en outre prévu, notamment au niveau des SAPI qui ne sont plus maintenues et qui devraient donc être supprimées.

Il reste de plus quelques patches à intégrer, relatif à la gestion des signaux au niveau du Zend Engine et à la gestion des erreurs, qui devraient être plus explicite avec cette nouvelle version.

Un patch permettant également de faire appel à un attribut ou une méthode de classe aussitôt un appel à l'opérateur new devrait également être intégré.

Enfin, il faut également que les contributeurs s'assurent que la documentation relative à l'installation de PHP 5.4 est à jour.

La liste des choses à faire au niveau technique est donc encore longue, et la liste fonctionnelle n'est pas en reste, car de nombreux points, souvent très conflictuels au sein de la communauté, doivent encore être évoqués.

Les contributeurs semblent vouloir entre autre réserver un espace de nom au langage, qui pourrait être \php.

Cependant, pour l'instant, il n'est pas précisé l'usage qu'il pourrait en être fait à l'avenir dans la feuille de route, et je n'ai pas encore pris le temps de rechercher des informations complémentaires.

Ils doivent également discuter de la pertinence de transformer int, float et les autres types natifs en mot réservé, dans l'optique de mettre en place un jour le contrôle de type sur les arguments.

L'idée n'est donc pas encore abandonnée, malgré les débats houleux qu'elle a suscité par le passé parmi les développeurs de PHP.

L'erreur E_STRICT pourrait de plus faire parti de E_ALL avec PHP 5.4, et il pourrait être possible d'avoir au sein de $_POST les données brutes reçues par le serveur.

Le support de la notation binaire pour les entiers est également au programme et viendrait, si elle était adoptée, compléter la notation octale et hexadécimale.

Les magic quotes, l'un des plus gros boulets historiques du langage, pourrait de plus venir s'ajouter à la liste des boulets supprimés, qui contient déjà les directives safe_mode, register_globals ainsi qu ses dérivés.

En terme de syntaxe, la possibilité d'utiliser une syntaxe plus courte pour la définition des tableaux devrait être à nouveau discutée, peut être grâce à l'arrivée sur internals@ de Robert Eisele, l'auteur du fork récent de PHP qui intègre une telle fonctionnalité.

Et si les discussions aboutissent, PHP 5.4 devrait disposer d'un serveur web intégré destiné au développement (et uniquement au développement).

Enfin, les contributeurs veulent également parler de l'utilisation d'une classe native pour la gestion des sessions, et du fait de pouvoir imposer un type callback pour un argument de fonction ou de méthode.

Le programme pour les mois à venir est donc précis, mais chargé.