PHP releases and support

PHP is used extensively on the web. How new features, security fixes, and bug fixes make their way into a release is important to understand. Likewise, understanding what can be expected in community support for previous releases is even more important. Since PHP-based sites are typically exposed to the Internet, keeping up-to-date is not something a security-minded administrator can afford to ignore.

PHP has not always had a formal release process and corresponding time frame for support; the official policy the project has now wasn't adopted until 2011. Before then, the decisions of when to make releases and how long to support them were both made less formally by key members of the community.

Let's start with PHP versioning, where the project is more or less dependable. The versioning of PHP releases aims to follow Semantic Versioning. Major releases such as 3.0 and 4.0 always come with backward-compatibility breaks. Minor versions, such as 4.1 and 4.2, fix bugs and add new features that are backward-compatible in relation to the major release. Patch releases, such as 4.1.1, tend to be strictly for important bug fixes and should never break backward compatibility.

Note that these guidelines are by no means a hard and fast rule, however, as contributor Stanislav Malyshev points out:

While we cannot provide an accurate estimate to how often backward-compatibility is broken in minor and patch releases, it is not an entirely uncommon occurrence. For example, at least as recently as PHP 7.0.11, backward-compatibility breaks were introduced in bug fixes that subtlety changed the behavior of iconv_substr().

PHP version community support

Historically, once a version of PHP is released, how long it is supported by the community is another matter entirely. Consider the following table constructed from PHP releases dates taken from Wikipedia and end-of-life dates as reported by the project:

PHP Version	Release Date	End of Life	Support Time
4.0	May 22nd, 2000	June 23rd, 2001	13 months
4.1	December 10th, 2001	March 12th, 2002	3 months
4.2	April 22nd, 2002	September 6th, 2002	4 months
4.3	December 27th, 2002	March 31st, 2005	27 months
4.4	July 11th, 2005	August 7th, 2008	36 months
5.0	July 13th, 2004	September 5th, 2005	13 months
5.1	November 24th, 2005	August 24th, 2006	9 months
5.2	November 2nd, 2006	January 6th, 2011	50 months
5.3	June 30th, 2009	August 14th, 2014	61 months
5.4	March 1st, 2012	September 3rd, 2015	42 months
5.5	June 20th, 2013	July 21st, 2016	37 months
5.6	August 28th, 2014	December 31st, 2018	52 months
7.0	December 3rd, 2015	January 10th, 2019	37 months
7.1	December 1st, 2016	December 1st, 2019	36 months
7.2	November 30th, 2017	November 30th, 2020	36 months
7.3	December 6th, 2018	December 6th, 2021	36 months
7.4	November 28th, 2019	November 28th, 2022	36 months

Since the formal release process was adopted in 2011, around the time PHP 5.2 support was ended, this makes sense. According to the release process, PHP releases are based on a three-year life cycle. Each release is supported actively for two years from its official release date. During this time, the community fixes bugs, adds features, and fixes security vulnerabilities. After the two year period, security-related support for the release continues for another year.

According to the policies of the project, support for a specific version ends after three years. Hopefully, in the interim, the majority of applications running on that version of PHP migrate to a more recent version. It is a straightforward release policy, and certainly an improvement over no policy at all. However, things are more complicated than they seem — especially for major, or particularly popular, releases.

Complexities of PHP version support

Making sense of the historic inconsistencies behind the version support time frames requires a closer look at PHP developer metrics. Fundamentally, the PHP community hopes that its users, hosting providers, and distribution packagers will simply keep pace with PHP's release cycle. In fact, trying to encourage this is one of the reasons PHP tends to focus on backward compatibility. That hope, however, is not the reality. Looking at the current usage statistics. According to the May 2020 PHP-version usage statics from Packagist.com, 22% of deployments are using unmaintained versions of PHP. The problem is likely even more severe than this, as those statistics are based only on the version of PHP as reported during use of the Composer dependency manager — a relatively new addition to the PHP ecosystem yet to be adopted by major PHP-based projects like WordPress. W3Techs, using a more direct methodology, reports a much bleaker picture — 47% of relevant web sites having PHP 5 installed as of the time of this publication. That is a concerning statistic, since the last version of PHP 5 lost any support from the community almost a year and a half ago. Why these percentages are so large is a hard question to answer. Some users are likely completely unaware of the problem, others may simply be neglecting it by not updating their applications to work with a more modern version. The Composer-derived figures also better directly measure real PHP usage when compared to the W3Tech figures, which only report if a server has PHP installed. Either way, the community pays attention to these numbers and tends to support older-yet-popular releases longer. This is particularly true in the transitional period between major releases.

While the PHP project does have an official support policy, the reality is that it is often subject to change, with major releases historically deviating from the official policy. Looking back, PHP 4.x was maintained by the community for four years past the release of PHP 5.0, and for over eight years in total; a point made by Zeev Suraski when discussing ending support for PHP 5.6 after the release of PHP 7:

The reason the last release before a new major release gets special attention is all about user adoption. PHP 5 had significant backward-compatibility breaks in the object model compared to PHP 4, and likewise PHP 7 had backward-compatibility breaks when compared to PHP 5.6.

The incompatibilities of major releases extend beyond language features and behaviors alone. Another aspect of the problem is that non-core (PECL) extensions also need updating to be compatible with changes to the internals of PHP itself. If a given extension has Windows support, it may even require upgrading Microsoft Visual C++ in order for extension maintainers to catch up. Some extensions (such as one of mine) never make the jump, and are forever relegated to the abyss of PHP history. Why this happens varies, but it often has to do with how (un)popular an extension is to the broader PHP development community, versus the amount of maintainer effort required.

Backward-compatibility breaks, both in the language and extensions, hold adoption back. Meanwhile, the internals community tries to push both developers and extension maintainers into the future — major releases always implement important new features that the community wants hosting providers to adopt as quickly as possible. The longer support for an old version continues, the more likely everyone will drag their feet and stall adoption, as pointed out by Malyshev around the PHP 7 release:

All this complexity makes providing dependable version-support policies to users a challenge for PHP; it is largely dependent on something outside of the project's control — adoption. In contrast, the project itself from the beginning has always taken a release early, release often approach, a philosophy encouraged by the memory of the momentum lost to the project's over-reach around PHP 6's attempted transition to Unicode. These factors create a powerful influence, driving contributors to focus on faster releases and limited consensus over formal process. The result is a desire for frequent releases, with support for those releases often a secondary consideration.

These motivations haven't entirely prevented a degree of formality with regard to releases and support, just nowhere near what developers have come to expect from other languages. The less formal approach taken by the project has been successful, but hasn't always served the project well in the past, either. For example, during the PHP 4 to PHP 5 transition, it led to the end-of-life date for PHP 4 remaining undecided. That burden was something the community was determined to avoid in the jump from PHP 5.6 to PHP 7.0. In an attempt to balance the competing forces of forging ahead against user adoption, the community did eventually vote on a Request for Comments (RFC) led by Suraski to extend support for PHP 5.6. The result was extending the official policy to add a year of full support, followed by an extra two years of security support.

What this means for the future

As things stand, the policy on support for releases still doesn't address exceptions to account for the adoption rates that are a significant aspect of that decision. It only defines a minimum time a version will be supported and, over the years, the general support from the community has certainly become more dependable. On major releases specifically, it seems the community is content to hash out long-term support decisions when it becomes a problem to solve, rather than formalize a change in the policy to address it. The wisdom of that approach is debatable, and will likely lead to more passionate discussion on the issue around the time PHP 8 is officially released (which is currently scheduled for November 2020).

Based on past experience during the PHP 5.6 to PHP 7.0 transition it does seem likely that, with PHP 8 on the horizon, PHP 7 support will continue for a longer period of time than the official policy indicates. If the PHP 7 support timetable does extend, the final end-of-life date for it will be at least be clearly defined — the community needs to vote on an RFC to extend support of PHP 7 beyond the current policy. That means users trying to make plans for the future still have to wait until the official release of PHP 8.0 to find out exactly how long applications based on PHP 7 will be supported. PHP 7.4 is likely to be the last version of PHP 7, and officially it will only be supported for another two and a half years.

Like so many things regarding PHP, support and release cycles are not as predictable and consistent as many prefer. However, also like many things in PHP, version support has consistently improved as the project has matured. At the moment, it seems unlikely the opposing forces that drive these decisions will ever truly be reconciled, leaving PHP developers forced to contend with a degree of uncertainty that other languages lack.