Product Decisions This Supports

Build vs buy: 3.0.0 is a maintenance signal, not a feature release. The vendor shipped Laravel 13 support on the current framework release cadence, which is the main thing you buy when you adopt a package instead of maintaining one in-house. Treat continued framework currency as the value proposition, not the changelog contents.
Platform roadmap: this release forces a decision. v3 requires Laravel 10+ and PHP 8.2+, so any product line still on Laravel 9 or PHP 8.0/8.1 is now on a dependency that no longer receives updates. That belongs in the platform modernization plan as a dated constraint, not a backlog item.
Upgrade sequencing: because the major bump is driven purely by dropping runtimes rather than by API changes, the upgrade cost is mostly environmental (PHP version, framework version, CI images, hosting) rather than code rewrite. That makes it cheap for teams already current and a hard blocker for teams that are not — useful for segmenting the upgrade work.
Use cases: unchanged from v2. Teams that adopt v3 get the same package surface with Laravel 13 compatibility; there is no new capability to build a feature or launch around.
Support-window risk: dropping Laravel 9 and PHP 8.0-8.1 mirrors upstream end-of-life, so the vendor is not creating a gap — but it does mean the last version supporting older runtimes is 2.x, which will itself stop receiving fixes. Budget for it going stale.

When to Consider This Package

Adopt v3 if: you are on Laravel 10, 11, 12, or 13 and PHP 8.2+, you want a dependency that tracks framework releases promptly, and you can absorb a major-version bump on a normal dependency upgrade cycle. The breaking changes are environmental, so adoption is low-effort for a current stack.
Stay on 2.x temporarily if: you are mid-migration off Laravel 9 or PHP 8.0/8.1. Pin the current major, and set an explicit date to move — a pinned major is a deferral, not a plan.
Look elsewhere if: you need an LTS-style guarantee of API stability across framework majors, you support customers on PHP 8.0/8.1 with no upgrade path, or the package is a thin wrapper you could own in a few hundred lines. In that last case the recurring major-version churn is a cost you can avoid entirely.
Watch for: this release contains no deprecations, only removals. Confirm your own code does not rely on anything that was transitively available only via Laravel 9 support, and check that no other dependency pins you below PHP 8.2 before committing.

For executives: the dependency is actively maintained and already supports the newest Laravel release. The tradeoff is a required platform upgrade — PHP 8.2+ and Laravel 10+ — which is work we should be doing anyway for security and support reasons. The upgrade is a version bump, not a rewrite, and its cost is concentrated in infrastructure and CI rather than application code.
For engineering: 3.0.0 is a breaking major with no new features. It adds Laravel 13 support and removes Laravel 9 and PHP 8.0-8.1. Pin to 2.x on any service that cannot move to PHP 8.2 and Laravel 10 immediately, and file the upgrade as a scheduled task with an owner and a date rather than leaving the pin indefinite. Sequence the framework/PHP bump first, then take v3 — there is no reason to couple the two in a single change.
Decision requested: approve the platform upgrade window, and confirm which services, if any, need to remain on 2.x past the next quarter so we can size the exposure.