Laravel 9: New Release Cadence and PHP 8 Compatibility

Laravel 9 shipped in February 2022. It was a delayed release — originally expected by late 2021 before being pushed back. But what makes it interesting isn’t the delay; it’s the rhythm that crystallized alongside it: a new major version every February.

This post is less about what Laravel 9 actually introduced and more about what that annual cadence means for project management. The feature list is well documented elsewhere. What deserves more attention is how this rhythm plays out in practice.

What an annual release cadence actually means

As Laravel adopted the foundation Symfony provides, the long-running six-month minor release model gave way to something more intuitive. A major version every February, with 18 months of active support per major and a 12-month security-only window after that.

The practical impact on project planning is concrete: when kicking off a project, the question isn’t just “which Laravel version” but “does the support lifetime of this version align with the expected lifespan of this project?” Laravel 9’s active support runs through 2023 — enough for a long-lived product, and a non-issue for anything short-term.

For teams, it also brings standardization. The question “when should we upgrade the framework?” now has a cleaner answer: a new major just dropped, we’ll evaluate the upgrade during the next big refactoring cycle. Planned, not reactive.

PHP 8.0 as the minimum requirement in practice

Laravel 9 dropped PHP 7 support entirely. PHP 8.0 is the minimum. The background here is the Symfony 6 dependency — Symfony 6 also requires PHP 8 — so anyone wanting to upgrade had no choice but to update their infrastructure as well.

The tools PHP 8.0 introduced — the match expression, named arguments, union types, the nullsafe operator — genuinely change how you write code. Laravel 9’s internals use them actively. You’re not forced to adopt them in your own codebase immediately, but once you look at the PHP underneath the framework, you can see how widespread they’ve become.

A practical example: Laravel 9 added Route::controller() support. Instead of repeating the same controller class over and over:

use App\Http\Controllers\OrderController;

Route::controller(OrderController::class)->group(function () {
    Route::get('/orders', 'index');
    Route::post('/orders', 'store');
    Route::get('/orders/{id}', 'show');
});

A small quality-of-life improvement, but it meaningfully reduces repetition in large route files.

Changes to the bootstrap file

Laravel 9 also brought a cleaner structure to bootstrap/app.php. On its own, that’s not worth making a big deal of — but it’s a preview of the far more radical simplification that arrived in Laravel 11. The framework’s long-term direction is clear: less boilerplate, more explicit configuration.

The cost of upgrading

In practice, upgrading to Laravel 9 is manageable for most projects. The significant change is the PHP version; if you’re already on PHP 8, the friction is low. Running php artisan migrate and composer update, then letting your test suite run, is generally the right starting point.

Where you need to be careful: your own packages and community packages. Major packages in the ecosystem tend to update quickly, but niche dependencies warrant a closer look. Taking the output of composer outdated seriously is not optional.

Making version tracking a habit

The annual release cadence gives us something valuable: predictability. February comes around, you read the release notes, understand what changed, skim the upgrade guide. This is not a sprint — it’s an hour-long investment.

The surprises developers run into during major version upgrades are almost entirely avoidable. The framework telegraphs where it’s heading well in advance. Reading is enough.

Laravel 9 is not a revolutionary release in terms of features. But in terms of cadence, it marks a point of maturity. Adapting to this rhythm is the path of least resistance to keeping your framework version current across a project’s lifetime.