The fourth Thursday in November of every year is a special day for people working on and with PHP.

On that day, the release managers of PHP release a new major or minor PHP version. On that day, two years after its initial release, another PHP version reaches the end of active support. And on that day, three years after its initial release, another PHP version reaches the end of security support, and thus, its end of life.

If you work with PHP, whether you like it or not, you are subject to the lifecycle of a PHP version. If you work with PHP, the question for you is how you align yourself with the lifecycle of a PHP version.

A PHP version policy can help you with that.

PHP version support policy for PHP applications

If you build, maintain, and run a PHP application in production, you have control over the environment in which that PHP application runs. You decide which PHP version that application uses and whether and when you update to a new PHP version.

Typically, a PHP application runs on one PHP version only. If your PHP application supports more than one PHP version and you have control over the environment in which that PHP application runs, you would always prefer to run the PHP application on the newest PHP version, or would you not? Supporting more than one PHP version does not make sense for a PHP application unless you are not running it yourself.

A PHP version support policy for a PHP application states how you commit to updating that PHP application to a new PHP version in alignment with the lifecycle of a PHP version.

A PHP version support policy for a PHP application could state the following:

The maintainers of this application will update to a new major or minor PHP version within three months after its release.

Whether you find such a PHP version support policy reasonable depends on whether you and your team can update that PHP application to a new PHP version within three months. You can start with a more relaxed PHP version support policy and tighten it as you become better at maintaining your PHP application.

Updating to a new PHP version may require development work. If your PHP application currently uses a PHP version that has reached its end of active or security support, then that PHP application is already one or more major or minor PHP versions behind. If you do not know how to update your PHP application to a new PHP version but also do not plan to sunset that application or go out of business soon, get help like everyone else. There is no shame in accepting and admitting that you have painted yourself into a corner.

By adopting a PHP version support policy for your PHP application, you manage expectations for when stakeholders can expect you to update a PHP application to a new PHP version.

By committing to a PHP version support policy for your PHP application, you will more frequently update to a new PHP version.

By updating your PHP application more frequently to a new PHP version, you benefit from the upside and mitigate the downside of updating to a new PHP version as early as you can.

By adopting and committing to a PHP version support policy, you will become better at maintaining your PHP application. PHP version support policy for PHP packages If you build, maintain, and distribute a PHP package, you have limited control over the environments in which others consume that PHP package, but you can decide which PHP versions that PHP package supports.

Typically, a PHP package supports more than one PHP version. If people use that PHP package in a PHP application, they will have a much easier time updating their PHP application from one PHP version to another when they do not simultaneously have to update that PHP package. Instead, they probably want to update their PHP packages first, then update to a new PHP version. By supporting more than one PHP version, you make it easier for people using that PHP package to update to a new PHP version.

A PHP version support policy for a PHP package states how you commit to add and drop support for PHP versions in alignment with the lifecycle of a PHP version.

A PHP version support policy for a PHP package supporting two major or minor PHP versions could state the following:

The maintainers of this package add support for a PHP version following its initial release and drop support for a PHP version when it has reached its end of active support.

A PHP version support policy for a PHP package supporting three major or minor PHP versions could state the following:

The maintainers of this package add support for a PHP version following its initial release and drop support for a PHP version when it has reached its end of security support.

A PHP version support policy for a PHP package supporting four major or minor PHP versions could state the following:

The maintainers of this package add support for a PHP version following its initial release and drop support for a PHP version one year after it has reached its end of security support.

Whether you find a progressive or a more conservative PHP version support policy reasonable depends on your goals and maintenance budget. You can always relax your PHP version policy and tighten it when your goals change.

Adding support for a new PHP version close to its initial release to a PHP package may demonstrate that the package is well-maintained. If you fail to add support for a new PHP version to your PHP package, users may conclude that you have abandoned it.

Adding support for a new PHP version to a PHP package may require development work. If your PHP package supports many PHP versions, one of these PHP versions may have already deprecated a PHP feature that you use and rely on in that PHP package. The new PHP version may remove that PHP feature. Before you can add support, you must work around the removal of that PHP feature, which may include dropping support for a PHP version.

Adding support for a new PHP version to a PHP package may come prematurely. If people use your PHP package in other PHP packages, they will often ask to add support for a new PHP version as soon as the release managers of PHP create the branch for that PHP version - which is months before its initial release. Note that allowing users to install your PHP package on a PHP version differs from explicitly adding support for a PHP version. Using proper version constraints helps.

Dropping support for a PHP version without active or security support from a PHP package may also demonstrate that the package is well-maintained.

Dropping support for a PHP version from a PHP package may require some development work but will reduce the maintenance efforts for that PHP package. If your PHP package supports many PHP versions, you may have to manage multiple execution paths depending on the PHP version. If you drop support for a PHP version, you may be able to remove one or more of these execution paths.

Dropping support for a PHP version from a PHP package may reduce the environmental impact of that PHP package. If you support many PHP versions, you will need to run automated tests on all of these PHP versions in a continuous integration environment. By reducing the number of PHP versions you support, you reduce the number of test runs and the environmental impact of your PHP package.

Dropping support for a PHP version from a PHP package may allow you to use features present in newer PHP versions. If you support many PHP versions, you are limited to using the PHP features that are present in the lowest PHP version. You could use so-called polyfills, PHP packages that may partially or fully implement newer PHP features for older PHP versions. If you require polyfills in your PHP packages, the users of your PHP packages who do not need them may have to install or replace these polyfills in their PHP applications.

Dropping support for a PHP version may reduce the number of people who can use the latest version of that PHP package. If the latest version of that PHP package requires a PHP version that these people are unable or unwilling to update to, they can and will continue to use an older version of that PHP package. That may or may not be a problem, depending on what your PHP package does.

Dropping support for a PHP version may require persuasion. If you are one of many maintainers of a PHP package, you need to convince other maintainers that it is worth dropping support for a PHP version.

By adopting a PHP version support policy for your PHP package, you manage expectations for when users, contributors, and maintainers can expect you to add and drop support for a PHP version from your PHP package.

By committing to a PHP version support policy for your PHP package, you will more frequently drop support for a PHP version with less resistance from users, contributors, and maintainers.

By dropping support for PHP versions from your PHP package more frequently, you reduce the maintenance effort and environmental impact, you can use features of new PHP versions earlier, and last but not least, you increase the pressure on users of your PHP package to update their PHP applications to a new PHP version.

By increasing the pressure on users of your PHP package to update their PHP applications to a new PHP version, you become part of the tribe that moves the PHP ecosystem forward.

Have you adopted and committed to a PHP version support policy yet?