Par Pascal MARTIN le mercredi 29 octobre 2014

Cet article est aussi disponible en français.

You can follow me @pascal_martin, and there is an RSS feed of the posts I write in English.

I have collected data and written about usage of each PHP versions a few times already — up until now, always in French: this is the first time I’m doing this in English. The first time I’ve done this was in September 2011 and the most recent one was almost one year ago, in November 2013. At that time, PHP 5.2 was still representing 34.4% of PHP installations, with PHP 5.3 ahead with 48.7%.

The data presented in this post have been collected during the week-end of October 2014 18th. Stable versions of PHP are PHP 5.4.34 (which is called old-stable), PHP 5.5.18 and PHP 5.6.2. PHP 5.3 is not maintained anymore, since August 2014 14th and PHP 5.2 has been out of support for almost 4 years.

Web Servers

Before talking about PHP versions, here’s the list of web-servers I identified the most often while collecting data:

  • Apache: 5,644,243 — 58.65%
  • IIS: 1,496,967 — 15.56%
  • nginx: 1,410,170 — 14.65%
  • Others: 456,985 — 4.75%
  • GSE: 312,448 — 3.25%
  • cloudflare-nginx: 134,131 — 1.39%
  • LiteSpeed: 107,378 — 1.12%
  • Oversee Turing v1.0.0: 61,127 — 0.64%

As a graph only representing the first few results:

Apache is still in the first place — and by far — but it loses ground bit by bit, especially to nginx, which rose in one year from 7.9% to 14.8%. IIS remains at the second place, but could very well fall down one step before my next post!

Major versions of PHP

When it comes to major versions of PHP, there is no real surprise:

  • PHP 3: 415 — 0.02%
  • PHP 4: 106,866 — 4.15%
  • PHP 5: 2,470,731 — 95.84%
  • PHP 6: 36 — 0.00%
  • PHP 7: 3 — 0.00%

PHP 5 is first in line, far from the other versions1 — which is, let’s admit it, quite logical.

Still, a great number of servers are still running PHP 4 — its last version having been released in August 2008.

Minor versions of PHP

Going on with minor versions of PHP, for PHP >= 3.x and PHP <= 7.x and only keeping versions that have been detected at least 10 times, we’d get the following data:

  • PHP 3.0: 402 — 0.02%
  • PHP 3.2: 12 — 0.00%
  • PHP 4.0: 834 — 0.03%
  • PHP 4.1: 1,823 — 0.07%
  • PHP 4.2: 1,967 — 0.08%
  • PHP 4.3: 22,537 — 0.87%
  • PHP 4.4: 79,702 — 3.09%
  • PHP 5.0: 2,500 — 0.10%
  • PHP 5.1: 39,144 — 1.52%
  • PHP 5.2: 586,490 — 22.75%
  • PHP 5.3: 1,141,116 — 44.26%
  • PHP 5.4: 583,423 — 22.63%
  • PHP 5.5: 113,582 — 4.41%
  • PHP 5.6: 4,464 — 0.17%
  • PHP 6.0: 34 — 0.00%

And, as a graph:

The first interesting thing is that PHP 5.3, which has not been supported anymore for a few month, is still the most used PHP version with 44.3%, far ahead of PHP 5.2 and 5.4 which are pretty much each as used as the other, with 22.8% and 22.6%.

PHP 5.5, released in June 2013, only gets the fourth place, far behind the other three versions. And PHP 5.6, the stable version released at the end of August 2014, is pretty much invisible on this chart, with a really small 0.2% of all identified versions.

With more than 2/3 of all servers running versions of PHP that are no longer officially maintained2, I’m coming back to what I say each time I take a look at those numbers: recent versions of PHP really are not adopted fast enough and too many servers aren’t updated often enough!

Patch versions of PHP

Finally, if we take a look at patch versions of PHP 5.x, only displaying in this list the versions that are used the most3, we get the following data:

  • Pour PHP 5.0: the most used version is 5.0.4, with 0.06%.
  • Pour PHP 5.1: PHP 5.1.6 gets the first place, at 1.40%.
  • Pour PHP 5.2: here are versions with more than 0.5%:
    • 5.2.4: 16,109 — 0.65%
    • 5.2.5: 12,966 — 0.52%
    • 5.2.6: 58,772 — 2.38%
    • 5.2.9: 24,504 — 0.99%
    • 5.2.10: 19,529 — 0.79%
    • 5.2.13: 16,225 — 0.66%
    • 5.2.14: 15,734 — 0.64%
    • 5.2.17: 376,304 — 15.23%
  • Pour PHP 5.3: here too, versions with more than 0.5%:
    • 5.3.2: 36,505 — 1.48%
    • 5.3.3: 249,448 — 10.10%
    • 5.3.6: 16,333 — 0.66%
    • 5.3.8: 30,140 — 1.22%
    • 5.3.10: 108,865 — 4.41%
    • 5.3.13: 33,579 — 1.36%
    • 5.3.15: 12,839 — 0.52%
    • 5.3.23: 16,950 — 0.69%
    • 5.3.26: 28,704 — 1.16%
    • 5.3.27: 91,395 — 3.70%
    • 5.3.28: 210,465 — 8.52%
    • 5.3.29: 195,469 — 7.91%
  • Pour PHP 5.4: here are versions at more that 0.5% (and the last released version):
    • 5.4.4: 82,126 — 3.32%
    • 5.4.23: 13,759 — 0.56%
    • 5.4.24: 13,475 — 0.55%
    • 5.4.25: 13,650 — 0.55%
    • 5.4.26: 17,978 — 0.73%
    • 5.4.27: 24,689 — 1.00%
    • 5.4.28: 20,568 — 0.83%
    • 5.4.29: 27,846 — 1.13%
    • 5.4.30: 43,200 — 1.75%
    • 5.4.31: 66,772 — 2.70%
    • 5.4.32: 104,195 — 4.22%
    • 5.4.33: 77,474 — 3.14%
    • 5.4.34: 2,023 — 0.08%
  • Pour PHP 5.5:
    • 5.5.0: 953 — 0.04%
    • 5.5.1: 691 — 0.03%
    • 5.5.2: 309 — 0.01%
    • 5.5.3: 7,059 — 0.29%
    • 5.5.4: 1,005 — 0.04%
    • 5.5.5: 913 — 0.04%
    • 5.5.6: 1,561 — 0.06%
    • 5.5.7: 1,710 — 0.07%
    • 5.5.8: 1,374 — 0.06%
    • 5.5.9: 31,366 — 1.27%
    • 5.5.10: 2,287 — 0.09%
    • 5.5.11: 2,969 — 0.12%
    • 5.5.12: 3,031 — 0.12%
    • 5.5.13: 3,059 — 0.12%
    • 5.5.14: 5,117 — 0.21%
    • 5.5.15: 5,343 — 0.22%
    • 5.5.16: 23,864 — 0.97%
    • 5.5.17: 19,893 — 0.81%
    • 5.5.18: 1,054 — 0.04%
  • Et pour PHP 5.6:
    • 5.6.0: 2,743 — 0.11%
    • 5.6.1: 1,026 — 0.04%
    • 5.6.2: 692 — 0.03%

As a chart presenting all 5.x.y versions at more than 0.5% or with a version number greater than 5.4.04, we’d get:

Looking at this chart and the corresponding data, a few versions seem used more than the others:

  • PHP 5.1.6 (released in August 2006) is still here, probably because it was the version available for some entreprise (or derived) distributions (Redhat Entreprise, or CentOS 5).
  • For PHP 5.2:
    • PHP 5.2.17 (released in January 2011) is still the most used patch version of PHP, even considering all minor versions, with 15.23%.
    • PHP 5.2.6 (released in May 2008) comes on second place amongst 5.2.x versions. It was the default version of Debian Lenny and is still at 2.38%.
  • For PHP 5.3:
    • PHP 5.3.3 is the most used 5.3 version, with 10.10%. It’s the version of Debian Squeeze or CentOS 6.
    • PHP 5.3.10 came down from 7.2% to 4.41% in the last year: it was the default version of Ubuntu Precise (12.04LTS).
    • The three most recent versions of PHP 5.3 come after that, at 3.70% for PHP 5.3.27, 8.52% for PHP 5.3.28 and 7.91% for PHP 5.3.29 — updates to these versions probably correspond to hosting services that tend to use the most recent patch version available, but don’t want to update to the next (and maintained) minor version.
  • For PHP 5.4:
    • PHP 5.4.4 is number two for the 5.4 branch, with 3.32%. It’s the version of PHP of Debian Wheezy.
    • The last four releases of 5.4 are at 2.70% for PHP 5.4.31, 4.22% for PHP 5.4.32 and 3.14% for PHP 5.4.33 — PHP 5.4.34, which has been released only a few days ago, is for now only at a pretty shy 0.08%.
  • For PHP 5.5:
    • 5.5.3 is at 0.29%. It’s the default version of Ubuntu Saucy (13.10).
    • The first place, for the 5.5 branch, goes to 5.5.9 with its 1.27%: it’s the version used by Ubuntu Trusty (14.04LTS)
    • The most recent versions are at 0.97% for PHP 5.5.16, 0.81% for PHP 5.5.17 and 0.04% for PHP 5.5.18.
  • PHP 5.6 makes a shy debut here, with 0.11% for PHP 5.6.0, 0.04% for PHP 5.6.1 and 0.03% for PHP 5.6.2.

It’s nice to see that, for each minor version, the most recent releases are, in general, the ones used the most — even if many servers keep using the default versions provided by their distributions (which, for some, backport security fixes of later versions, without changing the version number of PHP).


I will not try to write a long analysis of “why” those numbers are what they are: it’s up to you, if you want to comment on the fact that old and obsolete versions are still used and that updates are not applied often enough…

That being said, as this is not the first time I do this kind of collection of data about installed PHP versions, I thought it might be interesting to draw a chart showing the evolution of these versions. As a consequence, the following chart presents the evolution of all minor versions of PHP, since September 20115:

PHP 5.5 and PHP 5.6, the current stable releases of PHP, are barely visible on this chart… It’s up to us to ensure this changes!

Method and amounts of data

To finish this post, here are a few notes about the way I got the data presented here:

  • I started with a list of more than 12 million domain names (from Alexa’s top 1M, wikipedia dumps, …).
  • Of those 12M domains, 10.4M have been resolved to IP addresses — the remaining 1.6M were probably too old and not valid anymore.
  • Amongst the 10.4 millions of HTTP requests I’ve done, around 25% of all responses have been identified as generated by PHP. More precisely, I’ve identified 2,578,278 responses as corresponding to some kind of PHP.

With this relatively high amount of data, statistics presented earlier should be quite correct, or, at least, give results and numbers close to reality…

The informations about software and PHP versions have been obtained from the X-Powered-By and Server headers of HTTP responses, after a HEAD request, for each one of the 10.4M domains, on domain.tld, with a fallback on www.domain.tld in case the first one failed.

If you want more informations, you can take a look at the two long comments — in French — I posted a while back, to answer to a few questions that had been asked to me: the first one, and the second one.

And, you, are you using an up-to-date version of PHP?

  1. As PHP 5 is far ahead other major versions, I won’t do a graph of those: it wouldn’t be of much interest! 

  2. Some distributions (especially the enterprises-oriented ones) backport security fixes to older PHP versions. Which means some PHP 5.2 and PHP 5.3 servers might not suffer from security problems that have been fixed only after official support ended for those versions. 

  3. With about one patch release each month on two maintained branches, the full list of path versions is getting a bit long — which means I will not reproduce it in full. 

  4. With that many patch versions of PHP, I chose to only display on this chart, so it remains easy to read, versions with more than 0.5% for the oldest ones, and all versions since PHP 5.4.0 (which means all patch versions of minor versions currently maintained). 

  5. Data presented on the evolution chart are in percents, to be independent of the number of hosts, which changes each time. Please note I haven’t collected those data regularly in time, which means there is not the same amount of time between each date! 

Par Pascal MARTIN le mardi 28 octobre 2014 2 commentaires

This post is also available in English.

J’ai plusieurs fois collecté des statistiques à propos de l’utilisation des différentes versions de PHP : la première fois était en septembre 2011 et la plus récente était il y a presque un an, en novembre 2013. À ce moment là, PHP 5.2 représentait encore 34.4% des installations de PHP, avec PHP 5.3 en tête à 48.7%.

Les données présentées dans cet article ont été collectées le week-end du 18 octobre 2014. Les versions stables de PHP sont alors PHP 5.4.34 (qui est qualifiée de old-stable), PHP 5.5.18 et PHP 5.6.2. PHP 5.3 n’est plus maintenue depuis le 14 août 2014 et PHP 5.2 n’est plus supportées depuis presque 4 ans.

Serveurs Web

Avant de commencer à parler de versions PHP, voici la liste des serveurs Web les plus fréquemment identifiés lors de ma collecte de données :

  • Apache : 5,644,243 — 58.65%
  • IIS : 1,496,967 — 15.56%
  • nginx : 1,410,170 — 14.65%
  • Autres : 456,985 — 4.75%
  • GSE : 312,448 — 3.25%
  • cloudflare-nginx : 134,131 — 1.39%
  • LiteSpeed : 107,378 — 1.12%
  • Oversee Turing v1.0.0 : 61,127 — 0.64%

Sous forme graphique, en ne représentant que les premiers résultats :

Apache est toujours en première place — et de loin — mais il perd petit à petit du terrain, principalement au profit de nginx, qui est passé en un an de 7.9% à 14.8%. IIS reste en seconde place, mais pourrait bien descendre d’un cran d’ici à ma prochaine collecte de données !

Versions majeures de PHP

Aucune surprise au niveau des versions majeures de PHP :

  • PHP 3 : 415 — 0.02%
  • PHP 4 : 106,866 — 4.15%
  • PHP 5 : 2,470,731 — 95.84%
  • PHP 6 : 36 — 0.00%
  • PHP 7 : 3 — 0.00%

PHP 5 est en tête, de loin1 — ce qui est, admettons-le, fort logique.

Toutefois, un nombre important de serveurs sont encore sous PHP 4, dont la dernière version a été publiée en août 2008.

Versions mineures de PHP

Si on passe aux versions mineures de PHP, pour PHP >= 3.x et PHP <= 7.x et en ne conservant que les versions qui sont remontées 10 fois ou plus, on obtient les données suivantes :

  • PHP 3.0 : 402 — 0.02%
  • PHP 3.2 : 12 — 0.00%
  • PHP 4.0 : 834 — 0.03%
  • PHP 4.1 : 1,823 — 0.07%
  • PHP 4.2 : 1,967 — 0.08%
  • PHP 4.3 : 22,537 — 0.87%
  • PHP 4.4 : 79,702 — 3.09%
  • PHP 5.0 : 2,500 — 0.10%
  • PHP 5.1 : 39,144 — 1.52%
  • PHP 5.2 : 586,490 — 22.75%
  • PHP 5.3 : 1,141,116 — 44.26%
  • PHP 5.4 : 583,423 — 22.63%
  • PHP 5.5 : 113,582 — 4.41%
  • PHP 5.6 : 4,464 — 0.17%
  • PHP 6.0 : 34 — 0.00%

Et sous forme d’un graphique :

Il est intéressant de noter que PHP 5.3, qui n’est plus maintenu depuis quelques mois, est toujours la version de PHP la plus utilisée avec 44.3%, loin devant PHP 5.2 et 5.4 qui sont quasiment à égalité, respectivement à 22.8% et 22.6%.

PHP 5.5, publiée en juin 2013, n’arrive qu’en quatrième place, loin derrière les trois autres versions. Et PHP 5.6, qui est la version stable publiée fin août 2014 fait une entrée timide dans ce classement, avec un petit 0.2% des installations identifiées.

Avec plus de deux-tiers des serveurs qui tournent sur des versions de PHP qui ne sont plus officiellement maintenues2, j’en reviens à ce que j’écris à chaque fois que je regarde ces chiffres : les versions récentes de PHP ne sont que beaucoup trop lentement adoptées et trop de serveurs ne sont pas suffisamment mis à jour !

Versions releases de PHP

Enfin, si on descend au niveau des versions release de PHP 5.x, en ne conservant pour l’affichage de cette liste que les versions qui sont le plus souvent utilisées3, on obtient les données suivantes :

  • Pour PHP 5.0 : la version la plus représentées est 5.0.4, avec 0.06% des installations.
  • Pour PHP 5.1 : PHP 5.1.6 remporte la première place, avec 1.40%.
  • Pour PHP 5.2 : voici les versions à plus de 0.5% :
    • 5.2.4 : 16,109 — 0.65%
    • 5.2.5 : 12,966 — 0.52%
    • 5.2.6 : 58,772 — 2.38%
    • 5.2.9 : 24,504 — 0.99%
    • 5.2.10 : 19,529 — 0.79%
    • 5.2.13 : 16,225 — 0.66%
    • 5.2.14 : 15,734 — 0.64%
    • 5.2.17 : 376,304 — 15.23%
  • Pour PHP 5.3 : ici aussi, voici les versions à plus de 0.5% :
    • 5.3.2 : 36,505 — 1.48%
    • 5.3.3 : 249,448 — 10.10%
    • 5.3.6 : 16,333 — 0.66%
    • 5.3.8 : 30,140 — 1.22%
    • 5.3.10 : 108,865 — 4.41%
    • 5.3.13 : 33,579 — 1.36%
    • 5.3.15 : 12,839 — 0.52%
    • 5.3.23 : 16,950 — 0.69%
    • 5.3.26 : 28,704 — 1.16%
    • 5.3.27 : 91,395 — 3.70%
    • 5.3.28 : 210,465 — 8.52%
    • 5.3.29 : 195,469 — 7.91%
  • Pour PHP 5.4 : voici les versions à plus de 0.5% (et la dernière version publiée) :
    • 5.4.4 : 82,126 — 3.32%
    • 5.4.23 : 13,759 — 0.56%
    • 5.4.24 : 13,475 — 0.55%
    • 5.4.25 : 13,650 — 0.55%
    • 5.4.26 : 17,978 — 0.73%
    • 5.4.27 : 24,689 — 1.00%
    • 5.4.28 : 20,568 — 0.83%
    • 5.4.29 : 27,846 — 1.13%
    • 5.4.30 : 43,200 — 1.75%
    • 5.4.31 : 66,772 — 2.70%
    • 5.4.32 : 104,195 — 4.22%
    • 5.4.33 : 77,474 — 3.14%
    • 5.4.34 : 2,023 — 0.08%
  • Pour PHP 5.5 :
    • 5.5.0 : 953 — 0.04%
    • 5.5.1 : 691 — 0.03%
    • 5.5.2 : 309 — 0.01%
    • 5.5.3 : 7,059 — 0.29%
    • 5.5.4 : 1,005 — 0.04%
    • 5.5.5 : 913 — 0.04%
    • 5.5.6 : 1,561 — 0.06%
    • 5.5.7 : 1,710 — 0.07%
    • 5.5.8 : 1,374 — 0.06%
    • 5.5.9 : 31,366 — 1.27%
    • 5.5.10 : 2,287 — 0.09%
    • 5.5.11 : 2,969 — 0.12%
    • 5.5.12 : 3,031 — 0.12%
    • 5.5.13 : 3,059 — 0.12%
    • 5.5.14 : 5,117 — 0.21%
    • 5.5.15 : 5,343 — 0.22%
    • 5.5.16 : 23,864 — 0.97%
    • 5.5.17 : 19,893 — 0.81%
    • 5.5.18 : 1,054 — 0.04%
  • Et pour PHP 5.6 :
    • 5.6.0 : 2,743 — 0.11%
    • 5.6.1 : 1,026 — 0.04%
    • 5.6.2 : 692 — 0.03%

Sous forme d’un graphique reprenant toutes les versions 5.x à plus de 0.5% d’utilisation ou dont le numéro est supérieur ou égal à 5.4.04, on obtient :

En consultant ce graphique et les chiffres correspondant, on identifie plusieurs tendances et plusieurs versions qui semblent plus utilisées que d’autres :

  • PHP 5.1.6 (qui a été publiée en août 2006) est toujours représentée, probablement parce que c’était la version disponible sur certaines distributions entreprise ou dérivées (Redhat Entreprise, ou CentOS 5).
  • Pour PHP 5.2 :
    • PHP 5.2.17 (publiée en janvier 2011) est encore la version release de PHP la plus utilisée, toutes versions mineures confondues, avec 15.23%.
    • PHP 5.2.6 (publiée en mai 2008) arrive en seconde position parmi les versions 5.2.x. Il s’agissait de la version proposée par défaut sous Debian Lenny et elle représente encore 2.38%.
  • Pour PHP 5.3 :
    • PHP 5.3.3 est la version la plus utilisée de la branche 5.3, avec 10.10%. Il s’agit de la version fournie sous Debian Squeeze ou CentOS 6.
    • PHP 5.3.10 est descendue de 7.2% à 4.41% en presque un an : il s’agissait de la version distribuée par Ubuntu Precise (12.04LTS).
    • Viennent ensuite les trois versions les plus récentes de PHP 5.3, à 3.70% pour PHP 5.3.27, 8.52% pour PHP 5.3.28 et 7.91% pour PHP 5.3.29 — les montées vers ces versions doivent correspondre à des hébergeurs qui ont tendance à utiliser la version release la plus à jour disponible, sans pour autant souhaiter effectuer une montée de version mineure (vers une version maintenue, s’entend).
  • Pour PHP 5.4 :
    • PHP 5.4.4 est numéro deux des versions 5.4, avec 3.32%. C’est la version fournie par Debian Wheezy.
    • Les quatre dernières versions de 5.4 sont quant à elles à 2.70% pour PHP 5.4.31, 4.22% pour PHP 5.4.32 et 3.14% pour PHP 5.4.33 — PHP 5.4.34, qui est sortie il y a quelques jours, n’étant pour l’instant qu’à un timide 0.08%.
  • Pour PHP 5.5 :
    • Pour ce qui est de PHP 5.5, la version 5.5.3 est à 0.29%. C’est la version fournie par défaut pour Ubuntu Saucy (13.10).
    • La première place, pour la branche 5.5, revient à PHP 5.5.9 avec ses 1.27% : c’est la version distribuée par Ubuntu Trusty (14.04LTS)
    • Les versions les plus récentes sont quant à elles à 0.97% pour PHP 5.5.16, 0.81% pour PHP 5.5.17 et 0.04% pour PHP 5.5.18.
  • PHP 5.6 fait une timide apparition, avec 0.11% de PHP 5.6.0, 0.04% de PHP 5.6.1 et 0.03% de PHP 5.6.2.

Il est agréable de constater que, sur chaque version mineure, les releases les plus récentes sont, globalement, les plus utilisées — même si de nombreuses installations restent sur les versions fournies par les distributions (qui, pour certaines, intègrent des correctifs de sécurité de versions supérieures, sans pour autant changer de numéro de version).


Fidèle à mon habitude, je ne ferai pas une longue analyse sur le pourquoi du comment des chiffres que j’ai présentés ici : libre à vous de commenter sur le trop grand usage de versions complètement obsolètes, et le manque de mise à jour que l’on peut, malheureusement, trop souvent constater…

Cela dit, puisque ce n’est pas la première fois que j’effectue ce processus de collecte de statistiques à propos des versions de PHP utilisées, je me suis dit qu’il pouvait être intéressant de tracer un graphe représentant l’évolution de ces utilisations.

Le graphe reproduit ci-dessous présente donc l’évolution de l’utilisation des versions mineures de PHP, depuis septembre 20115 :

PHP 5.5 et PHP 5.6, les versions actuellement stables de PHP, sont à peine visible… À nous de faire en sorte que cela change !

Méthode et volumes de données

Pour terminer, voici quelques brèves notes à propos de la façon dont j’ai obtenu les chiffres présentés ici :

  • Je suis parti d’une liste de plus de 12 millions de noms de domaines (obtenue depuis le top 1M Alexa, des dumps wikipedia, …).
  • Sur ces 12M domaines, 10.4M ont pu être résolus vers une adresse IP — les 1.6M restant étant probablement trop vieux et plus valides.
  • Sur les 10.4 millions de requêtes HTTP effectuées, environ 25% des réponses ont été identifiées comme générées par du PHP. Plus précisément, j’ai identifié 2,578,278 réponses comme correspondant à du PHP.

Avec ce nombre relativement conséquent de réponses, les statistiques présentées plus haut devraient avoir des chances d’être à peu près correctes, ou, tout au moins, de donner des résultats et chiffres relativement proches de la réalité…

Les informations de logiciels et de versions de PHP ont été obtenues en analysant les en-têtes X-Powered-By et Server des réponses HTTP obtenues en effectuant une requête HEAD, pour chacun des 10.4M de domaines, sur domaine.tld, en me rabattant sur www.domaine.tld si la première requête échouait.

Pour ceux qui voudraient plus de détails, je vous invite à lire deux commentaires romans que j’avais postés suite à l’article de janvier 2013, en réponses à quelques questions qui m’avaient été posées : le premier, et le second.

Et vous, utilisez-vous une version à jour de PHP ?

  1. PHP 5 étant loin devant toutes les autres versions majeures, je ne présenterai pas de graphique : il n’aurait pas un grand intérêt ! 

  2. Certaines distributions (principalement celles orientées entreprise) backportent des correctifs de sécurités vers les vieilles versions de PHP. Certains installations en PHP 5.2 ou 5.3 ne souffrent donc peut-être pas des failles de sécurité corrigées après l’arrêt de la maintenance officielle de ces versions. 

  3. À raison d’environ une release par mois sur deux branches maintenues en parallèle, la liste complète des versions releases se fait un peu longue — je ne la reproduit donc pas intégralement ici. 

  4. Avec autant de versions release de PHP, j’ai choisi de n’afficher sur ce graphique, pour qu’il reste lisible, que les versions à plus de 0.5% pour les plus anciennes et toutes les versions depuis PHP 5.4.0 (pour présenter l’ensemble des versions release de versions mineures aujourd’hui maintenues). 

  5. Les chiffres présentés sur le graphique d’évolution sont en pourcentages, afin d’être indépendants du nombre d’hôtes interrogés, qui varie à chaque série de collectes. Notez que les collectes n’ont pas été effectuées de manière très régulière dans le temps ; il n’y a donc pas le même écart entre chaque date ! 

Par Pascal MARTIN le jeudi 9 octobre 2014 2 commentaires

Cet article est aussi disponible en français.

When I was younger and/or still a student, I wasn’t really used to drinking coffee: I would have one every once in a while, but nothing more — and it was definitely not a habit.

The day I started working in a consulting firm1, I pretty much hadn’t taken a seat yet that one of my colleagues was asking me some “do you want a coffee?”. Considering the coffee machine would be a perfect way to get to know my colleagues2, I accepted. Same thing for other colleagues I took a coffee with the following days. Or even for new hires I welcomed later on, btw.

A couple of months after the end of my internship and my hiring, with a little help from the upcoming release of a large project and unreasonable work schedules, I was still fixing tickets, saying to myself “there, one last coffee”, at more than 9PM

I rapidly got to drinking 6 to 8 cups of coffee per day — you’d just have to count:

  1. A first one early in the morning, at home, just after waking up, while reading my RSS.
  2. A coffee when arriving at work around 8-9AM depending on the days, either while reading mails (alerts, crons, error reports, …) of the night, or having a coffee break speaking with other colleagues who had arrived early3.
  3. Another coffee in the middle of the morning, around 10AM.
  4. Yet another one at the end of the morning, around 11:45, before going to eat.
  5. A fifth one just before 2PM, before going back to work.
  6. A coffee in the middle of the afternoon, around 4PM — quite often, that one was the occasion for a coffee break spent with a colleague, speaking about a specific technical point of the project we were currently working on4.
  7. And, finally, a last one around 5:30PM, before ending the day.

It’s easy: counting the points above, I’m already at 7. And that was for a normal day: working longer in the morning and the evening, during days of rush, I would sometimes have one or two additional coffee(s)

Thinking about it, at a rate of about thirty (euro-)cents per coffee (especially during the years we had an automatic coffee dispenser at work) six or more times a day, it adds up to about 2€ (~ 2.5 USD) each day. Which represents a coffee-budget of about 400€ a year! And this doesn’t include the price of the one coffee I took every morning at home!

To those who, from time to time, were telling me “you’re drinking too much coffee”, I was answering “nah, no”: after-all, I wasn’t sleeping too bad and was feeling OK during the day (else, I was considering it was just because I was working too much).

On the other hand, almost every week-end, I was quite tired and I sometimes got headaches, especially on Sundays… Same thing during the holidays, when I often felt exhausted, even while sleeping a lot more than when working…

Last year, I kind of randomly (thanks Twitter) read an article explaining how coffee works in the brain5 and I realized tiredness and headaches during week-ends might be caused by a lack of coffee, as I was only rarely having coffee on Saturday and Sunday.

So, one summer Monday morning last year, I stopped drinking coffee. Well, I tried: at 11AM, I was already getting one ;-(

The following day, Tuesday, second try. More successful. But I felt a bit tired all day long. It was to be predicted…

Wednesday morning while going to work, standing in the moving subway, I was so tired I felt like I was going to fall. Still, the evening before, I had gone to bed early, as I was feeling tired, and I had slept a long night!

I remember some urgent / critical / important / … thing that felt on me that same Wednesday at work at the end of the afternoon: the first thought that came to my mind was “I need a coffee, rrrhhhaaaa a coffee I have to get a coffee, some coffee, I need a coffee!!!”.

In the end, I spent the whole week feeling tired6, sleeping a lot to compensate, and taking dolipranes one after the other to fight headaches that didn’t want to go away. I had to wait until Saturday before things began to get better, and Sunday afternoon to finally be OK.

That’s were this article’s title comes from: I kind of feel like I survived this week without coffee!

Still, I did that brutally, going straight from 6-8 cups of coffee per day to 0, which might explain these symptoms — at the risk of being considered as binary, I think it’s easier than going down bit by bit. That week and the following one, I was having water-breaks with colleagues on coffee-break :-D

The second week without coffee, everything was going fine.

And, of course, I re-started drinking coffee — one when waking up, a second one at 9:30AM after our stand-up meeting, and a third one at the beginning of the afternoon. I console myself thinking it was more reasonable than before!

After a few months, this year, I again had the impression I was tired during week-ends, with occasional headaches on Sundays. Less than last year, but still kind of the same thing.

So, during spring, I stopped again. I’ve had headaches for a few days, but less than last year — because it wasn’t the first time I was stopping? Or because I was having less coffee per day than before?

Now, I’m almost at five months without coffee. And, most importantly, I do not need coffee anymore, even when it comes to a big deploy at 4AM at work or a 10 hours long trip to go to holidays \o/.

Now, I have to find out if I’ll be able to just drink coffee from time to time, purely because I want to7… while not having a relapse!

  1. I did my end-of-studies internship in a consulting firm in 2006 and worked there for more than five years afterwards. 

  2. After all, it seemed to me quite important to get to known, at least a bit, colleagues with whom I would work. Fresh out of school, I thought that talking around a coffee was a good way to step in a new project without immediately entering some “here’s the code, good luck!” mode. I still believe that now, actually — probably even more than at that time! 

  3. I’ve never felt guilty for having a long coffee break before 9AM: even taking my time, I was still at my workstation before the time I was supposed to arrive at work. 

  4. The afternoon coffee break, far away from workstations, is a great way to think, often with two or three colleagues, in a more calm way than with a computer — it has often allowed us to get problems solved and stuff unlocked! 

  5. I don’t have the link anymore and cannot find it again. But it was about some chemical stuff in the coffee, that takes the place of other chemical stuff in chemical receivers linked to tiredness and/or sleep in the brain, which explains why coffee helps against tiredness and sleepiness. Of course, when one stops drinking coffee, the normal chemical stuff comes back to the receivers that were blocked by coffee, which causes an impression of tiredness. (Sorry for the chemical stuff, reading this article was a while ago; and it’s been many years since molecules were more than chemical stuff to me ^^). Thanks to @tut_tuuut for the link to the Your Brain On Coffee video, which explains the same idea in a short and easy way! 

  6. I’m saying I felt like I was tired, because I was getting long nights and was sleeping enough for my body to be OK. I was feeling tired, but in parallel I don’t think I was less efficient in my work (but I might have been a bit more grumpy?). 

  7. As long as it’s not a matter of having 6-8 cups per day, I like the taste of coffee and drinking some hot beverage (especially in the morning during winter). So, I will probably drink some one day or the other: after-all, why not? 

Par Pascal MARTIN le mardi 7 octobre 2014

Cet article est aussi disponible en français.

730 messages have been exchanged in September 2014 on PHP’s internals@ mailing-list — almost the same number as in August.

As a graph representing the number of mails per month for the last three years, we’d get:

At the beginning of the month, Andrea Faulds wrote an RFC called “Implicit isset() in Shorthand Ternary Operator”. Its idea was to modify the ?: operator introduced with PHP 5.3 to automatically add an isset() and, so, prevent any notice from being raised.

The first answers indicated that the idea could be interesting, but, at the same time, several voices said changing the behavior of ?: in such a way might not be quite a good idea.

In the end, most of this RFC has been rewritten, leading to RFC: Null Coalesce Operator. The idea is now to add a new ?? operator, instead of changing the behavior of ?:. This new operator can be used like this:

// Uses $_GET['user'] if it exists -- or 'nobody' if it doesn't
$username = $_GET['user'] ?? 'nobody';

// Loads some data from the model and falls back on a default value
$model = Model::get($id) ?? $default_model;

With 31 votes “yes” and 3 votes “no”, this revamped version of the RFC has passed, which means PHP 7 will have a new ?? operator.

Leigh has written the RFC: loop + or control structure, which aims to add an optional block to PHP loops (for, while, foreach). This block would be executed in cases we don’t enter inside the loop (as the condition has not been true, even at first try). It would be introduced by the or keyword.

With this RFC, we could write something like this:

foreach (generator() as $k => $v) {
    // loop body
or {
    // executed if we never entered the
    // body of the foreach loop

This feature already exists in some templating languages — for instance, it is supported by Twig for its for loops, using the else keyword.

Note: using or would mean not adding a new reserved word, and else, which is used by other languages, cannot be used for PHP as it would lead to ambiguities in the language.

A few other things have been talked about in the conversation (we’ll see if someone pushes them farther, via other RFCs?), like the idea for a loop to systematically return the number of iterations done.

Robert Stoll suggested PHP 7 might be an occasion to make transtyping operations more strict. For example, (int)"a" would not longer be 0 and it would raise an error. Andrea Faulds quickly answered that explicit casts cannot fail and changing this behavior now would cause an incredible amount of bugs and BC-breaks.

Still, it might be possible to add some new transtyping functions that would be more strict — maybe like ext/filter already does? Another approach could be to use new keywords, like int('2'), or even a syntax close to constructors, like $a = new int('2').

Nikita Popov has written the RFC: Remove alternative PHP tags, which proposes to remove, for PHP 7, the alternative tags <% ... %> and <script language="php"> ... </script>.

Several answers have been quite positive, but others noted a script to facilitate the migration to <?php ... ?> would be helpful.

Votes have been opened a few days before the end of the month and results should be there at the beginning of October. For now, things seem to be going well for this RFC.

Levi Morrison noted that what is usually called type-hints are definitely not hints, as types fixed when declaring a function or a method are checked and an error is raised if passed parameters don’t match them. As a consequence, he asked if someone had a better name idea, or if we were going to keep calling those hints.

Andrea Faulds suggested Optional Type Declarations for parameters and Return Type Declaration for the return-type. As those types are not optional once they are set, Type Declarations might be a good compromise — or maybe Type Assertions.

On the other hands, Type Hints has been used for years in the manual and by the community… In the end, I’m curious to see if this proposal will go farther and if, one day, we’ll stop talking of hints for things that are actually not.

Tjerk Meesters noticed the tests of ReflectionFunction::isDeprecated() depend, for now, on functions flagged as deprecated — but, as those might get removed for PHP 7, these tests might have to be updated.

That test might also be fixed, so it finds a deprecated function by itself. Or, instead, would it not be interesting for PHP to define a __deprecated__() function, that would forever be flagged as deprecated — even if it would only exist when PHP is compiled in debug-mode?

During the conversation, Alexander Lisachenko noted that adding a deprecated keyword, that could be used from user-space, might be an interesting idea, especially for some big frameworks. I wonder if this idea has not already been suggested in the past…

Dmitry Stogov has written the RFC: Fix list() behavior inconsistency, which suggests to remove a few inconsistencies of list() when it comes to strings. Today, using list() on a string works, or not, depending on the situation:

list($a,$b) = "aa"; // $a and $b are NULL
$a[0]="ab"; list($a,$b) = $a[0]; // $a is 'a' and $b contains 'b'

For PHP to be more consistent, this RFC proposed to forbid using list() on strings, or to make it work in all cases. As Derick Rethans indicated, the second option would add a new behavior to PHP, while the first one would come to removing something that works today (even if not documented).

Votes have been opened right before the end of September. Considering how things are going for now, it is very likely something will be done, but it’s hard to predict which one of those two approaches will win.

I was saying last month a mailing-list had been setup for members of the French UG AFUP, to discuss, in French, about proposals that were announced on internals@.

Following our discussions of this month, I (as I’m acting as its coordinator) posted a summary of AFUP’s members’ opinion on three threads:

In addition, we now have a blog. I’ll try posting, mainly in French, about the opinions we have expressed on internals@, and, if possible, a few sentences to summarize the goal of each RFC and why we’ve spoken the way we did: PHP Internals en français

Matt Wilmas worked on a patch that would bring a micro-second resolution (with a good precision) to functions such as microtime(). It might be added to a next minor version of PHP 5.6.

Andrea Faulds opened votes on RFC: Scalar Type Hinting With Casts, before pausing them to give people more time to discuss the matter… And, in the end, the RFC has been withdrawn.

Leigh proposed adding two new format codes to pack() and unpack(), related to 64 bits. RFC: 64 bit format codes for pack() and unpack() has been posted a few days later. This RFC passed, with 15 votes “yes” and 0 votes “no”.

Here’s another RFC written by Andrea Faulds: RFC: ZPP Failure on Overflow. It started off the fact that, today, when a floatting-point number too big to fit in the range of an integer is passed as a parameter to an internal function (exposed by PHP or an extension) that expects an integer, it is received by this function as… an integer… which causes loss of data. This RFC proposes that, when an integer is expected as a parameter and the received value is a float that cannot fit in an integer, the parsing of the parameters of the function fails, and a warning gets raised.

At the beginning of the month, Levi Morrison announced votes were being opened on RFC: Make defining multiple default cases in a switch a syntax error. With 28 votes “yes” and 0 votes “no”, it passed: it will not be possible anymore, with PHP 7, to write more than one default section in a single switch construct.

In the middle of September, Andrea Faulds indicated the beginning of the voting phase on RFC: Integer Semantics. With 16 votes “yes” and 8 votes “no”, it seems this RFC passed — even if votes got closed pretty much a day too early.

Kris Craig wrote the RFC: Change checkdnsrr() $type argument behavior, to change the default behavior of checkdnsrr(), to fetch more than only MX records.

And, finally, Nicolai Scheer noticed it isn’t possible to use an object as an array key, even if it defines a __toString() method: this one is not automatically called. Calling __toString() automatically in such a situation doesn’t seem right, as this method is used by some to produce a printable version of an object. Instead, a new magic method __toKey() could be added, so __toString() continues to return a printable string, while this new method would return a more technical identifier. is the mailing-list of the developers of PHP; it is used to discuss the next evolutions of the language and to talk about enhancement suggestions or bug reports.
This mailing-list is public and anyone can subscribe from the page Mailing Lists, or read its archives using HTTP from php.internals or through the news server news://

Par Pascal MARTIN le mardi 7 octobre 2014 1 commentaire

This post is also available in English.

Septembre 2014 a vu 730 messages échangés sur la mailing-list internals@ de PHP, soit quasiment le même nombre qu’en août.

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient :

Je disais le mois dernier qu’une mailing-list avait été mise en place pour les membres de l’AFUP, en vue d’échanger en français sur les propositions annoncées sur internals@.

Suite aux discussions que nous avons eu ce mois-ci, j’ai (en tant que coordinateur de celle-ci) posté l’avis de l’AFUP sur trois sujets :

En complément, nous disposons maintenant d’un blog où j’essayerai de poster régulièrement, principalement en français, les opinions que nous avons exprimées sur internals@, ainsi que, dans la mesure du possible, quelques phrases résumant en quoi consistent chaque RFC et pourquoi nous nous sommes exprimés comme nous l’avons fait : PHP Internals en français

Au début du mois, Andrea Faulds a rédigé une RFC nommée “Implicit isset() in Shorthand Ternary Operator”, qui proposait de modifier l’opérateur ?: introduit avec PHP 5.3 pour qu’un isset() soit automatiquement ajouté et, donc, qu’aucune notice ne soit levée.

Les premiers retours ont montré que l’idée pouvait être intéressante, mais, en parallèle, plusieurs voix ont souligné qu’il n’était peut-être pas judicieux de modifier le comportement de l’opérateur ?: de la sorte.

Finalement, cette RFC a été en grande partie ré-écrite, pour arriver à RFC: Null Coalesce Operator, qui proposait d’ajouter un nouvel opérateur ??, au lieu de modifier le comportement de ?:. Ce nouvel opérateur pourrait être utilisé de la manière suivante :

// Utilise $_GET['user'] si existe et 'nobody' sinon
$username = $_GET['user'] ?? 'nobody';

// Charge une donnée depuis le modèle et se rabat sur une valeur par défaut
$model = Model::get($id) ?? $default_model;

Avec 31 votes “pour” et 3 votes “contre”, cette version revue de la RFC est passée et PHP 7 disposera donc d’un nouvel opérateur ??.

Leigh a rédigé la RFC: loop + or control structure, qui propose d’ajouter un bloc, optionnel, aux structures de boucles (for, while, foreach) de PHP. Ce bloc serait exécuté dans le cas où on n’entre jamais dans la boucle (la condition n’étant pas vérifiée, et ce dès le premier passage). Il serait introduit par le mot-clef or.

Avec cette RFC, il deviendrait possible d’écrire quelque chose de ce type :

foreach (generator() as $k => $v) {
    // corps de la boucle
or {
    // exécuté si on n'est pas entré
    // dans le corps de la boucle foreach

C’est une fonctionnalité qui existe déjà dans certains langages de templating — par exemple, Twig supporte ceci pour ses boucles for, en utilisant le mot-clef else.

Il est à noter qu’utiliser or éviterait d’ajouter un nouveau mot réservé et que le mot-clef else employé par d’autres langage ne semble pas pouvoir être utilisé par PHP, car il mènerait à des ambiguïtés.

Quelques autres idées ont été levées dans la conversation (à voir si quelqu’un les poussera en avant à travers d’autres RFC ?), comme la possibilité qu’une boucle puisse systématiquement retourner le nombre d’itérations effectuées.

Robert Stoll a suggéré que PHP 7 pourrait être l’occasion de rendre les opérations de transtypage plus strictes, de manière à ce que, par exemple, (int)"a" ne vaille plus 0 et lève une erreur. Andrea Faulds a rapidement répondu que les casts explicites ne pouvaient pas échouer et que changer ce comportement maintenant mènerait à une quantité incroyable de bugs et de BC-breaks.

Par contre, une possibilité pourrait être d’ajouter de nouvelles fonctions de transtypage plus strictes — peut-être comme ce que fait déjà ext/filter ? Passer par de nouveaux mot-clefs comme int('2') ou même une syntaxe proche de celle utilisée pour les constructeurs, comme $a = new int('2'), pourrait être une autre approche.

Nikita Popov a rédigé la RFC: Remove alternative PHP tags, qui proposait de supprimer, pour PHP 7, les tags alternatifs <% ... %> et <script language="php"> ... </script>.

Une partie des retours ont été plutôt positifs, mais d’autres ont souligné qu’il serait bon de fournir un script facilitant la migration vers <?php ... ?>.

Les votes ont été ouverts vers la fin du mois et les résultats devraient arriver tout début octobre — les choses semblant plutôt bien parties pour cette RFC pour l’instant.

Levi Morrison a noté que ce qui est généralement appelé type-hints ne sont absolument pas des hints (“hint” se traduisant par “indice” ou “astuce”), puisque les types indiqués lors de déclarations de méthodes et fonctions sont vérifiés et que des erreurs sont levées si les paramètres passés ne correspondent pas à ceux-ci. Il a donc demandé si quelqu’un avait une meilleure proposition de nom, ou s’il fallait rester sur celui-ci.

Andrea Faulds a proposé Optional Type Declarations pour les paramètres et Return Type Declaration pour le type de retour. Ces types n’étant pas optionnels une fois qu’ils ont été positionnés, Type Declarations constituerait un bon compromis — ou peut-être Type Assertions.

D’un autre côté, Type Hints est utilisé depuis des années dans le manuel et par la communauté… Je suis donc curieux de voir si cette proposition aboutira et si on cessera un jour de parler de hints pour quelque chose qui n’en est pas.

Tjerk Meesters a remarqué que les tests de la méthode ReflectionFunction::isDeprecated() dépendent, aujourd’hui, de fonctions marquées comme obsolètes — mais, comme elles pourraient être supprimées de PHP 7, ces tests seront à revoir.

Le test en question pourrait aussi être modifié pour trouver par lui-même une fonction obsolète. Ou, à la place, est-ce qu’il ne serait pas intéressant que PHP définisse une fonction __deprecated__(), qui soit éternellement marquée comme obsolète — quitte à ce qu’elle n’existe que lorsque PHP est compilé en mode debug ?

Dans la conversation, Alexander Lisachenko a noté qu’ajouter un mot-clef deprecated qui puisse être utilisé depuis l’espace utilisateur serait peut-être une alternative intéressante, notamment pour certains gros frameworks. Je me demande d’ailleurs si cette idée n’avait pas déjà été évoquée par le passé…

Dmitry Stogov a rédigé la RFC: Fix list() behavior inconsistency, qui proposait de supprimer quelques inconsistences de list() par rapport aux chaînes de caractères. En effet, aujourd’hui, utiliser list() sur une chaîne de caractères fonctionne ou non selon les cas :

list($a,$b) = "aa"; // $a et $b valent NULL
$a[0]="ab"; list($a,$b) = $a[0]; // $a vaut 'a' et $b vaut 'b'

Pour rendre PHP plus cohérent, cette RFC proposait de complètement interdire l’utilisation de list() sur des chaînes de caractères, ou alors que la rendre possible dans tous les cas. Comme l’a fait remarquer Derick Rethans, la seconde option ajouterait un comportement fonctionnel à PHP, alors que la première reviendrait à supprimer quelque chose qui marche aujourd’hui (même si non documenté).

Les votes ont été ouverts quelques jours avant la fin du mois. Vu l’orientation qu’ils prennent, il est fort probable que quelque chose soit fait, mais il est difficile de prédire laquelle des deux approches sera privilégiée.

Matt Wilmas a travaillé à un patch permettant d’avoir une résolution à la microseconde (avec une bonne précision) pour les fonctions comme microtime(). Il pourrait être intégré pour une prochaine version mineure de PHP 5.6.

Andrea Faulds a ouvert les votes sur la RFC: Scalar Type Hinting With Casts, avant de les mettre en pause pour laisser le temps à plus d’échanges sur le sujet… après lesquels la RFC a été retirée.

Leigh a proposé d’ajouter de nouveaux codes de formats à pack() et unpack(), pour ce qui est 64 bits. La RFC: 64 bit format codes for pack() and unpack() a été rédigée quelques jours plus tard. Cette RFC est passée, avec 15 votes “pour” et 0 vote “contre”.

Voici une autre RFC proposée par Andrea Faulds : RFC: ZPP Failure on Overflow. Elle est partie du constat que, aujourd’hui, lorsqu’un flottant trop grand pour tenir dans les valeurs supportées pour les entiers est passé en paramètre à une fonction interne (fonction exposée par PHP ou par une extension PHP) qui attend un entier, il est reçu par la fonction sous la forme… d’un entier… ce qui entraîne une perte d’information. Cette RFC propose donc que, dans le cas où un paramètre entier est attendu et que la valeur reçue est un flottant trop grand pour tenir dans un entier, l’analyse des paramètres de la fonction interne appelée échoue, que la fonction retourne sans s’exécuter, et qu’un avertissement soit levé.

Au début du mois, Levi Morrison a annoncé l’ouverture des votes sur la RFC: Make defining multiple default cases in a switch a syntax error. Avec 28 votes “pour” et 0 vote “contre”, elle est passée : il ne sera donc plus possible, en PHP 7, d’écrire plusieurs sections default dans un même bloc switch.

En milieu de mois, Andrea Faulds a annoncé l’ouverture des votes sur la RFC: Integer Semantics. Avec 16 votes “pour” et 8 votes “contre”, elle semble être passée — même si les votes ont été clos pas loin d’un jour en avance.

Kris Craig a rédigé la RFC: Change checkdnsrr() $type argument behavior, qui propose de modifier le comportement par défaut de la fonction checkdnsrr() pour charger plus que les informations d’enregistrements MX.

Et enfin, Nicolai Scheer a fait remarquer qu’il n’était pas possible d’utiliser un objet comme clef d’un tableau, même s’il définissait une méthode __toString() : celle-ci n’est pas automatiquement appelée. Appeler automatiquement __toString() dans ce cas de figure ne semble pas optimal, puisque cette méthode est utilisée par certains pour produire une version affichable d’un objet. À la place, une nouvelle méthode magique __toKey() aurait l’avantage de laisser à __toString() le soin de renvoyer une chaîne utilisable pour affichage, alors que cette nouvelle méthode renverrait un identifiant plus technique. est la mailing-list des développeurs de PHP ; elle est utilisée pour discuter des prochaines évolutions du langage, ainsi que pour échanger autour de suggestions d’améliorations ou de rapports de bugs.
Elle est publique, et tout le monde peut s’y inscrire depuis la page Mailing Lists, ou consulter ses archives en HTTP depuis php.internals ou depuis le serveur de news news://