Back2Front Laravel Laravel Package

Product Decisions This Supports

• Framework upgrade sequencing. This release aligns the package with Laravel 13.x and sets a floor of Laravel ^11.0. That makes it a direct input to our Laravel upgrade roadmap: any application still on Laravel 10 must either upgrade the framework before taking this version, or pin the package to the previous minor line. The PM decision is an ordering constraint, not a feature decision — figure out which of our services sit on L10 and budget accordingly.
• Support matrix and deprecation policy. The project is now maintaining three Laravel majors (11, 12, 13). That is a healthy signal but also a support-cost signal: it tells us the maintainers are tracking upstream releases promptly, which reduces the risk of us being stranded on an unsupported framework version.
• Build vs. buy. Continued upstream maintenance of framework compatibility is exactly the kind of "boring" work we should not be doing ourselves. Each release like this strengthens the case for staying on the package rather than maintaining an in-house fork — a fork would inherit this same compatibility treadmill plus our own divergence.
• Security and patch cadence. Dropping an older Laravel major is a leading indicator of where the project will stop shipping fixes. If we have long-lived deployments, this release is the moment to schedule their exit from L10 rather than discover it when a CVE lands.
• CI and tooling baseline. PHP 8.5 in the Docker container, Composer 2.10, and PHPUnit ^10.5.35 are development-environment changes. They should not affect our production runtime, but they do tell us the project tests against modern PHP — useful when we plan our own PHP 8.4/8.5 migration.
• Not supported by this release: no new user-facing features. Do not use it as a marketing or roadmap input.

When to Consider This Package

Adopt (or upgrade to) this release when:

• You are on Laravel 11, 12, or 13 (or planning to be within your current upgrade cycle). This version is squarely aimed at you.
• You want to stay on a maintained line. Taking the latest minor keeps you eligible for upstream fixes and avoids a painful multi-major jump later.
• You are planning a PHP version migration. The project's move to PHP 8.5 in CI is a reasonable proxy for forward compatibility, though you should confirm the runtime php constraint in composer.json rather than inferring it from the Dockerfile.
• You need Laravel 13 readiness. If Laravel 13 is on your roadmap, this release is a prerequisite for that workstream.

Look elsewhere, or defer, when:

• You are pinned to Laravel 10 or earlier. This release will not install. Stay on the prior minor and treat the L10 end-of-life as a scheduled project, not an emergency — but do schedule it.
• You require a package that guarantees long-term support for older framework majors. Nothing here indicates an LTS branch for L10 users; verify before committing.
• You need net-new capability. There is none in this release. If you are evaluating the package on features, this release is not the data point you want.
• Verification gaps you should close before adopting: (1) confirm the runtime PHP floor in composer.json, since the notes only mention the Docker image; (2) confirm the actual illuminate/* constraint range, since the notes describe it in prose; (3) confirm whether the L10 drop was released as a minor. Dropping framework support in a minor version is technically a breaking change — if that is what happened, note it as a semver-policy observation, because it predicts how future breaks will be delivered to us.

How to Pitch It (Stakeholders)

For executives (one paragraph): The package shipped a maintenance release that adds support for Laravel 13 and drops Laravel 10. There is no new functionality and no action required for teams already on Laravel 11 or newer. For any product still on Laravel 10, this is an early signal that support for that framework version is winding down across our dependency chain — it belongs in next quarter's planning as a scheduled upgrade, not a fire drill. The commercial read is positive: an actively maintained dependency is a cheaper dependency than one we fork and own.

For engineering leads: Treat this as a compatibility gate, not a feature drop. Confirm the runtime PHP and illuminate/* constraints from composer.json before planning, since the notes only describe the CI environment. Sequence any upgrade as Laravel first, then this package — the reverse order will not resolve. Flag it in the dependency review if the Laravel 10 drop shipped in a minor release; that is a semver-policy signal worth tracking for future upgrade planning. Low urgency for L11+ services, low effort, no user-visible change.