PHP Community Support Lifecycle Changes: What Do They Mean for Your Team?

The PHP release cycle sets an aggressive pace with a feature release occurring once per year. Since 2011, this lifecycle has followed the same timeline. However, in November of 2024, a few significant changes and features will be introduced to the PHP release cycle.

In this blog, I discuss the traditional PHP release cycle, break down the upcoming changes to PHP community support timelines, and explore the ramifications these shifts and adjustments may have for your team and PHP applications.

What Is the PHP Release Cycle?

Currently, PHP provides two release cycles: one for regular maintenance and security patches, and another for feature releases.

Feature releases happen on an annual basis, generally on the last Thursday of November (yes, this is Thanksgiving in the United States!). These will be either a new minor release (e.g. 8.3), providing only new features (and deprecations, if features are slated to be removed in an upcoming major release), or a new major release (e.g. 8.0). Major releases occur for a few reasons:

• To remove existing features or to change signatures of existing features. When this happens, any code that uses those features will require changes. As such, these changes are backwards incompatible with existing releases, so the new major release is an indication you may need to make changes to your code so it will continue to run.
• To make engine changes that change how PHP extensions will interact with the engine. Just as with feature removals or signature changes, these changes have implications for existing extensions that will require updates in order to compile and run against this version of PHP.

Feature releases, whether via a new minor or major version, are supported for 3 years: 2 years with both bugfixes and security fixes, and an additional year of security fixes only.

Maintenance releases also happen on a regular cadence. Maintenance releases are made against versions currently receiving bugfixes, and, if a security fix is required, versions that are eligible for security fixes. These happen every 4 weeks, on Thursdays. As such, they generally happen on a monthly cadence, but there are occasions where 2 releases will occur in a given month.

Initial Release

Once a new feature version is released, the countdown begins. A release only receives active support for 2 years, and then an additional year of security support.

Active Support

Active support includes bugfixes. These may be issues created in the given feature release, but they can also be issues only reported while a release is in active support. Regardless, the PHP maintenance volunteers will triage the issue, attempt to reproduce it, and, if successful, identify a fix. These fixes are never backported to versions that have fallen outside the support window.

Security Support

Security support involves any fix that patches a reported vulnerability in the language. These can range in severity, but the PHP project tries to patch any reported issue so long as the PHP version is still in the security support window. Reports are generally made directly to language maintainers, but occasionally will be reported to CVE authorities outside those channels.

End of Life

Once the two years of active support and one additional year of security-only support are complete, a PHP feature version is considered end of life, and receives no more updates from the PHP project itself. Some Linux distributions and commercial entities will continue to backport and apply security patches to these versions, but official support is complete.

Keep Informed With the Zend 2024 PHP Landscape Report

Join me as I discuss our findings from our annual survey of 500+ PHP developers and administrators. Learn about key shifts in PHP usage and 2024's top emerging trends.

Download Our Free Report

PHP Release Cycle Updates

Leading up to the PHP 8.4 release, the PHP project voted on a proposal that changes this lifecycle in a few important ways.

Security Support Extended by One Year

First, and most importantly, each feature release now gets an additional year of security support. This means that from the duration from release until it goes end-of-life is now 4 years instead of 3. Each version still only receives 2 years of active (bugfix) support.

This change goes into effect starting with PHP 8.1, meaning PHP 8.1 will not reach end of life at the end of this year per its previously published schedule.

Release Cycle Extended to End of Year

Second, instead of the PHP lifecycle being measured in absolute years, the lifecycle extends through December 31 of the last year of security support. This makes the end date for each version more predictable and allows for a minimum of a month of overlap between a version going end of life and a new version being released.

This change also goes into effect starting with PHP 8.1, meaning that its EOL date is now December 31, 2025.

Features Allowed That do Not Require an RFC in the Beta Period

Part of the existing release policy is that while language change proposals (traditionally called Request for Comments, or RFCs, the term I will reference from this point forward) must have completed voting prior to the beta release cycle, they can be implemented during the beta release cycle. However, no other changes have been allowed during that period, even changes that do not require an RFC.

With the newly adopted changes to the RFC process, this restriction has been lifted.

New Features Disallowed in Release Candidates and Bug Fix Releases

Similarly, the process has allowed small, self-contained features to be added both during the release candidate phase, as well as in bugfixes for actively supported feature releases. As noted in the process release policy changes, “small” and “self-contained” are highly subjective and can lead to widely different interpretations. With the process release changes, such additions are no longer allowed during those phases.

Number of RCs Reduced to Four

Under the existing process, the PHP project has scheduled 6 release candidates for each feature version. What the project has found is that (a) not enough people test these, and (b) the cycle impacts normal development on the language. As such, the new process reduces the number of release candidates to 4.

Recent Regression Fixes Allowed During Security Support

Sometimes a bugfix can lead to a regression (introduction or re-introduction of a bug). If this situation is corrected on an actively supported version, it could mean that a version currently in security-only status still has the regression, making it less stable, even though it is still receiving security patches.

Under the new policy, regression fixes made within 12 months of a version entering security-only status will be backported to that version.

PHP Moves Fast—Are You Keeping Up?

PHP constantly evolves to keep pace with modern DevOps demands. With each new iteration building on the previous version, staying informed on past shifts and ongoing changes is critical.

Explore the Evolution of PHP

How PHP Release Cycle Changes Impact Your Team

As with any change or shift in PHP processes, these new PHP lifecycle changes will have an impact on your team, application, and planned projects in a few notable ways.

First, these changes mean that organizations deploying PHP applications have an additional year of security support from the PHP project. For some companies, this may mean that they can keep their applications satisfying security and compliance requirements for longer without needing to migrate to a newer version or investigate Long Term Support options.

Second, because regressions will be addressed for essentially an extra year, they can rely on the stability of PHP for a longer period of time. Many organizations try and stay only on versions receiving active support due to the fact that they can then be assured of regression fixes; however, with only two years, this can often mean yearly updates just to keep their applications on current PHP versions. They can now likely extend this lifecycle by at least a year.

Finally, for many organizations, 4 years is still likely not long enough; many organizations want 5-7 year application lifespans. What the change does do, however, is shorten the length of time they will require an LTS edition of the runtime.

Final Thoughts

The PHP ecosystem is constantly adapting to keep pace with evolving DevOps needs, and the PHP release cycle is no exception. While your team can now take advantage of the extra year of security support, along with the other new changes, it is still critical to prepare for when your current PHP version reaches end of life. 

Whether you are planning ahead or currently running a PHP version that is no longer community supported, your best solution is to partner with an experienced team of PHP experts, such as Zend. For decades, we have supported PHP teams through many updates and modifications, and we’re ready to assist you during these upcoming lifecycle changes.

Stay Secure With ZendPHP

ZendPHP provides secured runtimes and comprehensive support for mission-critical applications. Maintain compliance, access 24/7/365 support, and upgrade PHP versions on your schedule—regardless of PHP community support changes.

Discover ZendPHP  See PHP LTS Options

Additional Resources

• White Paper - Planning Your Next PHP Migration
• White Paper - The Hidden Costs of PHP Upgrades
• Webinar - PHP Roundup: Navigating PHP 8.0 End of Life and Exploring PHP 8.3
• Resource - PHP Versions: Performance, Security, and Feature Comparisons
• Blog - PHP Migration Trends to Watch in 2024
• Blog - 2024 PHP Report Overview: PHP App Development and Deployment Trends
• Blog - PHP 8.0 EOL Is Here: What Now?
• Blog - Unpacking the Drupal PHP Support Lifecycle
• Blog - Why Good PHP Monitoring Matters