Il y a eu quarante-six modifications effectuées sur le trunk de PHP au cours de cette période.

Pour la première fois en cent jours, la majorité de ces modifications sont des corrections, puisqu'il y en a pratiquement une trentaine.

Les bug #51552, #52019, #52060, #52057, #52051, #49320, #52067, #52043, #52082, #52041, #51424, #51424, #51002, #42060, #50578, #50563, #52098, #52101, #51424, #52115, #52086, #52010, #51295, #45808, #45876, #38955 et #48632 ont donc été corrigés.

Les principaux bénéficiaires de ces corrections sont debug_backtrace(), la gestion de la mémoire, mysqli, GD, crypt(), openssl, PDO et FPM ainsi que les archives phar.

Le reste des modifications correspond à l'ajout de tests ainsi qu'à quelques améliorations.

Il est ainsi par exemple possible d'écrire cela :

<?php
fonctionQuiRenvoitUnTableau()[1] = uniqid();
?>

Au final, il n'y donc rien de bien palpitant à se mettre sous la dent au niveau du trunk.

À contrario, la liste de diffusion des contributeurs, internals@, a été beaucoup plus intéressante.

En effet, le débat concernant l'ajout de fonctionnalités spécifique à un SGBD au niveau du pilote PDO, entamé sur la précédente période, s'est poursuivi et se poursuit encore.

À la lecture des différents points de vue, j'ai compris que personne ne sait actuellement ce que va devenir PDO.

Il y a bien une réflexion en cours sur le wiki, mais les divergences d'opinions sur le sujet sont tellement importantes qu'il est difficile de dire ce qu'il va en ressortir au final.

Pour l'instant, le trunk a été modifié pour permettre l'ajout de fonctionnalités spécifiques à postgresql d'une manière qui se veut générique, mais qui est loin de faire l'unanimité.

Il faut dire que PDO est un projet délicat et complexe, puisque son but est d'uniformiser la manière d'utiliser un SGBD dans le cadre de PHP.

Il souffre de plus d'un certain nombre de bugs et son développement demande des compétences élevées, sans compter que de plus, son créateur, Wez Furlong, n'a pas de temps à y consacrer actuellement, alors qu'il a écrit la majorité du code.

Tout cela fait donc que PDO n'évolue pas et que personne n'en dirige réellement le développement, d’où les discussions actuelles sur  internals@ à son sujet.

Personnellement, je trouve cela relativement inquiétant pour son avenir, puisque c'est à peu prés le même genre de situation qui a provoqué l'arrêt du développement de PHP 6.

Dans un autre registre, il se pourrait que le support de sqlite dans sa version 2 soit retiré de la prochaine version de PHP, tout comme celui de mysql via les fonctions mysql_*, avantageusement remplacées par mysqli.

Si cela est quasiment certain en ce qui concerne sqlite, il y a encore des discussions au sujet de mysql, puisqu'il existe énormément de documentations, de livres et d'exemples mettant en œuvre ces fonctions.

Il y a également une discussion en cours pour décider si APC doit être intégré dans le langage et s'il doit être activé par défaut lors de l'installation de PHP.

Cette solution de cache devait en effet être intégré dans PHP 6, et en conséquence, la question est à nouveau posée dans le cadre du nouveau trunk.

Cependant, certain ne semble pas voir d'un bon œil cette intégration, car cela revient à donner à APC une position prédominante par rapport à d'autres système de cache tel que xcache.

Il se pose également la question de la fiabilité d'APC et de sa compatibilité avec PHP 5.3, qui ne semble pas être assurée à ce jour.

Enfin, la licence d'APC sous windows ne semble pas être compatible avec la licence de PHP.

Tout cela est donc l'objet de discussions actives qui ont fini par étouffer, j'espère définitivement, le débat sur le contrôle du type des arguments, même si je n'ai actuellement pas connaissance d'un vote qui aurait fait émerger une solution définitive sur ce point précis.