PHP Version Guide

Can This Project Use This PHP Feature?

A feature being available in PHP does not mean it is available to every project. The oldest runtime promised by the project is what matters. If production still runs PHP 8.1, a developer using PHP 8.5 cannot safely commit property hooks or the pipe operator.

Use the version-specific lessons for complete release changes. Use this page for a quick first-availability check and then verify the project's real compatibility boundary.

Quick Availability Table

The table lists representative language features, not every change in each release.

First available Representative features
PHP 7.0 Scalar parameter types, return types, ??, <=>, anonymous classes
PHP 7.1 Nullable types, void, iterable, class constant visibility
PHP 7.2 object parameter and return type
PHP 7.3 Trailing commas in function and method calls
PHP 7.4 Typed properties, arrow functions, ??=, array unpacking with integer keys
PHP 8.0 Union types, attributes, named arguments, match, nullsafe operator, constructor property promotion
PHP 8.1 Enums, readonly properties, intersection types, never, first-class callable syntax
PHP 8.2 Readonly classes, disjunctive normal form types, stand-alone true, false, and null types, #[\SensitiveParameter]
PHP 8.3 Typed class constants, #[\Override], dynamic class constant fetch
PHP 8.4 Property hooks, asymmetric property visibility, #[\Deprecated], lazy objects
PHP 8.5 Pipe operator, #[\NoDiscard], clone() with changed properties, URI extension

"First available" means the feature should not be used as part of the project's contract until all runtimes that must parse or execute the relevant code support that version.

Find The Project's Real Minimum

Do not decide from the PHP version on one laptop. Check all of these:

  1. The PHP constraint in composer.json.
  2. Production web and command-line runtimes.
  3. Queue workers, scheduled jobs, and deployment utility containers.
  4. Every PHP version in the CI matrix.
  5. Static analysis, coding-standard, test-runner, and IDE language-level settings.
  6. The minimum PHP version promised by a reusable package to its consumers.

Useful local evidence includes:

php -v
composer check-platform-reqs
composer show --platform

To investigate whether dependencies permit a proposed PHP 8.3 baseline:

composer prohibits php 8.3

Also inspect Dockerfiles, deployment manifests, CI workflows, hosting configuration, and worker images. A web container on PHP 8.3 does not help if a PHP 8.1 queue worker later parses the same source tree.

Composer Constraint Versus Actual Runtime

A Composer requirement declares the versions the project supports:

{
  "require": {
    "php": "^8.1"
  }
}

For PHP 8, ^8.1 permits versions from PHP 8.1 up to, but not including, PHP 9.0. More importantly, it promises that the application or package works on PHP 8.1. Code committed under that constraint must therefore remain compatible with PHP 8.1 unless the baseline is deliberately raised.

Composer's config.platform.php setting can make dependency resolution behave as though it were running on a selected PHP version. It does not change the interpreter that executes the application. A build can resolve packages for PHP 8.1 while a developer accidentally uses PHP 8.4 syntax unless linting and CI also run against the minimum version.

composer check-platform-reqs checks the PHP version and extensions available in the environment where the command runs. It does not prove that every production node or worker has the same runtime.

Example Decision: A PHP 8.1 Application

Assume a project declares "php": "^8.1", its oldest production node runs PHP 8.1, and developers use PHP 8.5.

Proposed code Decision Reason
Add an enum Allowed Enums are available from PHP 8.1
Add a readonly property Allowed Readonly properties are available from PHP 8.1
Mark a class readonly Not yet Readonly classes require PHP 8.2
Add #[\Override] Not yet The built-in attribute requires PHP 8.3
Add a property hook Not yet Property hooks require PHP 8.4
Use the pipe operator Not yet The pipe operator requires PHP 8.5

The developer's PHP 8.5 runtime can run all of that code, but the PHP 8.1 production node defines the safe language level.

Raising The Baseline Safely

Changing composer.json is not the first or only upgrade step. A safer sequence is:

  1. Choose the target PHP version and read every intervening migration guide.
  2. Check framework, dependency, extension, and hosting compatibility.
  3. Update CI to test the target while retaining the current minimum during the transition.
  4. Upgrade production images, workers, scheduled jobs, and developer tooling while the code still uses the older syntax.
  5. Prove the application on the target runtime with tests, static analysis, smoke checks, and representative traffic.
  6. Remove the old runtime, raise the Composer constraint and tool language levels, then permit features from the new minimum.

Deploying the newer runtime before merging incompatible syntax avoids a mixed fleet where old processes cannot parse newly deployed files.

For a library, raising the constraint is a compatibility decision for consumers and may require a major release according to the project's versioning policy.

Language Features, Functions, And Extensions

This table focuses mainly on language features. A function or class can have an additional extension requirement. Before using an API, check both:

  • the PHP version where the API first appeared;
  • whether its extension is installed in every required environment.

For example, PHP 8.5's URI extension is always enabled in PHP 8.5, while many database, image, internationalisation, and XML APIs depend on extensions that can be absent from a particular build.

What This Reference Is For

Use this page when reviewing new syntax, planning a modernization, or deciding whether a library can raise its minimum PHP version. It is a lookup and decision aid, not an upgrade checklist and not a substitute for the official migration guides.

The defensible answer to "can we use this feature?" should name the feature's first PHP version, the project's verified minimum runtime, and the evidence showing every execution environment satisfies that minimum.

Practice

Practice: Review Features Against A PHP 8.1 Baseline
{
  "require": {
    "php": "^8.1"
  }
}

Its environments are:

  • production web nodes: PHP 8.1 and PHP 8.2 during a rolling migration;
  • queue workers: PHP 8.1;
  • CI: PHP 8.1 and PHP 8.3;
  • developer laptop: PHP 8.5.

A pull request proposes:

  • an enum for order status;
  • a readonly property on an order value object;
  • a readonly class;
  • #[\Override] on inherited methods;
  • property hooks;
  • the pipe operator.

Write the code-review decision for each proposed feature.

Requirements

  • Name the first PHP version supporting each feature.
  • Use the oldest runtime that executes the application, not the developer laptop.
  • Explain what the ^8.1 constraint promises.
  • Identify commands and repository files that provide compatibility evidence.
  • Describe a safe sequence for raising the baseline to PHP 8.3.
  • Explain why changing only composer.json would not make PHP 8.3 syntax safe.
Show solution

The effective minimum is PHP 8.1 because production nodes and queue workers still execute the application on that version. The PHP 8.5 developer laptop does not raise the project's compatibility boundary.

Proposed feature First available Review decision
Enum PHP 8.1 Approve
Readonly property PHP 8.1 Approve
Readonly class PHP 8.2 Reject until the baseline is raised
#[\Override] PHP 8.3 Reject until the baseline is raised
Property hooks PHP 8.4 Reject until the baseline is raised beyond the proposed PHP 8.3 target
Pipe operator PHP 8.5 Reject until every required runtime reaches PHP 8.5

The Composer constraint ^8.1 permits Composer to resolve on supported PHP 8 releases, but it also declares PHP 8.1 as a supported minimum. Shipping PHP 8.2 syntax while retaining that promise would make the package or application unparsable on a permitted runtime.

Collect evidence with:

php -v
composer check-platform-reqs
composer show --platform
composer prohibits php 8.3

Then inspect composer.json, composer.lock, CI workflows, Dockerfiles, deployment manifests, hosting configuration, worker images, static-analysis configuration, and IDE language-level settings. Run syntax and test checks on the minimum supported PHP version.

To raise the baseline to PHP 8.3:

  1. Review the PHP 8.2 and PHP 8.3 migration guides.
  2. Confirm dependencies and required extensions support PHP 8.3.
  3. Add or retain PHP 8.3 CI coverage and resolve failures.
  4. Upgrade every web node, worker, scheduler, and deployment utility to PHP 8.3 while the source remains PHP 8.1-compatible.
  5. Run tests, static analysis, smoke checks, and deployment verification.
  6. Remove PHP 8.1 and PHP 8.2 execution paths.
  7. Change the Composer minimum and tool language levels to PHP 8.3.
  8. Merge PHP 8.3-only features such as #[\Override].

Changing only composer.json alters dependency resolution and the declared support contract. It does not replace the PHP 8.1 interpreter running a queue worker or production node, so that process could still fail when parsing newer syntax.