Product Decisions This Supports
- Platform upgrade sequencing. 0.6.0 is a hard gate: the package now requires PHP ≥ 8.4 and Laravel ≥ 13, with no functional changes. That makes it a clean forcing function — you cannot adopt this package on Laravel 12 or PHP 8.3, and you cannot stay on it while deferring a runtime upgrade. If this package is on your critical path, its 0.6.0 line effectively sets your minimum platform version.
- Build vs. buy / dependency triage. The release tells you more about the maintainer's operating model than about features: they ship support for a new Laravel major immediately and drop everything older in the same release. That is a deliberate, low-overhead maintenance posture. It's attractive if your own cadence matches, and a liability if it doesn't — quantify that before it lands in a dependency tree you have to defend.
- Roadmap and support-matrix planning. Because the package tracks only the newest Laravel major, your supported-versions matrix for customers is now bounded below by Laravel 13. If you sell to customers on Laravel 11/12 or PHP 8.2/8.3 — common in regulated or long-lived deployments — this release is a customer-facing compatibility event, not a routine bump.
- Upgrade cost estimation. The breaking changes are entirely environmental, so the migration cost is your platform upgrade cost, not a code rewrite. That is the cheapest possible form of breaking change and worth calling out explicitly when scoping work.
- CI and test-matrix decisions. Adopting 0.6.0 means dropping PHP 8.3 and Laravel ≤12 from your own test matrix for any package that depends on this one. Budget that as a one-time engineering task rather than an incidental.
- Vendor due diligence signal. A maintainer willing to cut a major for a support-window change — rather than carrying compatibility shims — is a good signal for maintenance health and a warning against assuming stability guarantees. Neither is decisive on its own; both belong in the evaluation.
When to Consider This Package
Consider it when:
- You are already on, or committed to, Laravel 13 and PHP 8.4 in the near term and can absorb the floor without a parallel upgrade programme.
- You are starting greenfield and want a dependency that will not accumulate legacy-version branches.
- Your release cadence is fast and you would rather upgrade on the maintainer's schedule than carry compatibility code.
- You have a pinned, versioned dependency strategy (lockfile discipline, staged rollouts) so that a major release is a scheduled event rather than a surprise.
Look elsewhere, or pin deliberately to the 0.5.x line, when:
- You support Laravel 11 or 12, or run PHP 8.2/8.3, anywhere in production — including in customer-hosted deployments you don't control.
- You need a dependency with an LTS-style guarantee or a documented deprecation window longer than one major.
- The package sits on a critical path and your organization requires security patches for older platform versions; this project's support window is strictly narrower than Laravel's own.
- You have no visibility into the package's functional scope yet — the release notes here describe version support only, so confirm the actual capability set and API stability before committing.
For anything already in the dependency tree, treat 0.6.0 as a planned upgrade tied to your Laravel 13 migration, not an opportunistic bump.
How to Pitch It (Stakeholders)
For executives: A dependency we are evaluating shipped a major release whose only changes are platform requirements — it now requires the newest PHP and Laravel versions and has dropped all older ones. There are no new features and no API changes, so the risk is not code breakage; it is scheduling. Adopting it ties us to a Laravel 13 / PHP 8.4 upgrade, and staying on it means we upgrade whenever the maintainer does. The trade-off is a lean, actively maintained dependency against a support window narrower than the framework's own. Recommendation: adopt where we are already on Laravel 13, hold at the previous major everywhere else, and confirm the functional capability set before wider rollout.
For engineering: 0.6.0 is a support-matrix break, not an API break. Adds Laravel 13; drops PHP < 8.4 and Laravel < 13. Plan it as part of the Laravel 13 migration: update the CI matrix, audit transitive dependents, and keep the 0.5.x line pinned for any service or customer deployment not yet on the new floor. Note that the package supports only the latest Laravel major — there is no backport path, so any security or bug fix from here forward will require the platform upgrade first.