Product Decisions This Supports
- Framework upgrade timing (Laravel 5.8 → 6.x): v2.0.0 explicitly adds Laravel 6 support. This package is no longer a blocker on the Laravel 6 upgrade path — it can be treated as a "green" dependency in the upgrade plan, which lets us sequence the remaining work around dependencies that are still blocking.
- Build vs. buy / dependency strategy: The release cadence and the willingness to drop unsupported framework versions are a positive maintenance signal. It argues for continuing to consume this package rather than building a thin in-house equivalent, provided our own support window matches theirs.
- Platform baseline decision (PHP 7.2+): The new floor of PHP 7.2 and Laravel 5.8 sets a hard constraint on our hosting images, CI matrix, and any long-lived client installations. This forces an explicit decision: upgrade those environments, or freeze those apps on v1.x.
- Legacy estate segmentation: The v2.0.0 requirement change gives us a clean, verifiable line between "modern" apps (5.8+/PHP 7.2+, adopt v2) and legacy apps (≤5.7, stay on v1.x). Useful for scoping a technical-debt backlog item rather than discovering it mid-sprint.
- Use cases unlocked: Any feature work targeting Laravel 6 apps can now include this package in scope. Feature work on ≤Laravel 5.7 apps continues on the v1.x line and should be treated as maintenance-only.
When to Consider This Package
Adopt / upgrade to v2.0.0 when:
- The application runs Laravel 5.8 or 6.x and PHP 7.2+.
- We want to stay on a maintained branch that tracks current framework versions.
- The upgrade is being bundled into an existing framework upgrade rather than done as a standalone change.
Pin to v1.x (defer) when:
- Any application is still on Laravel 5.7 or older, or PHP below 7.2. v2.0.0 is a hard break for those environments.
- The app is in a change-freeze window and there is no security or functional driver to move.
Look elsewhere when:
- We need support for Laravel versions released after 6.x — the release note stops at 6, so future-cadence commitment is unconfirmed and should be validated before we treat this as a long-term dependency.
- The package is load-bearing for multiple legacy apps that cannot be upgraded together; maintaining two major versions across the estate may cost more than replacing it.
- Our security policy requires a documented support/EOL policy per major version, which this note does not provide.
Verification action before adopting: v2.0.0 is documented only as a requirements change (framework/PHP floors). The release note does not state whether the public API changed. Treat it as breaking-by-requirements and confirm via the changelog/upgrade guide and a test-suite run on 5.8 and 6.x before rollout.
How to Pitch It (Stakeholders)
For executives: This is a low-cost, low-risk maintenance release. The vendor raised the minimum supported platform to Laravel 5.8 and PHP 7.2 and added Laravel 6 support, dropping Laravel 5.7 and older. In practice it keeps the package aligned with the framework versions we actually intend to run, and it removes a dependency from the critical path of the Laravel 6 upgrade. The only real cost is that older applications must stay pinned to v1.x until they are upgraded — a known, bounded piece of technical debt rather than a new one.
For engineering: Expect no functional regressions if you are already on 5.8+/PHP 7.2+. The change is a major version bump because the support floor moved, not because new capability was added. Actions: (1) run the suite on both 5.8 and 6.x, (2) add PHP 7.2/7.3 to the CI matrix, (3) pin v1.x explicitly for legacy services so a routine composer update cannot pull v2 into an unsupported environment, and (4) confirm from the upstream changelog whether any API-level changes accompany the requirement bump — the release note does not say.