Product Decisions This Supports
- Platform upgrade sequencing. v7.0.0 requires PHP 8.3 and Laravel 13, so adopting it is not a standalone dependency bump — it is gated on our application runtime upgrade. This package's version number effectively becomes a milestone inside the Laravel upgrade epic, and product should plan them together rather than as two independent roadmap items.
- Support-window policy. The maintainer now supports only the latest Laravel major, with older lines unmaintained and "pin a tagged release" as the only recourse. That converts an engineering convenience into a product risk decision: any quarter where we trail Laravel by a major version, this package receives no fixes — including security fixes — and we own that exposure explicitly.
- Build vs. buy (consume vs. fork). If a roadmap commitment requires staying on an older Laravel past this package's support horizon, the realistic options are forking and self-maintaining, or replacing the capability. That is a costed decision, not a default, and it should be made once with a date attached rather than rediscovered at each release.
- Contribution and vendoring strategy. Removal of the Git pre-push hook and Scrutinizer CI means we can no longer treat the package's own pipeline as a quality or safety signal if we fork or vendor it. Any fork inherits that work; our CI must cover it.
- Developer-environment scope. The Podman-based
./dev flow removes host PHP/Composer requirements. This only affects our roadmap if we intend to contribute upstream or onboard engineers onto a fork — otherwise it is a non-factor.
Caveat: this assessment is derived from release metadata, not a capability audit. Confirm the package's functional scope before attaching it to a specific feature commitment.
When to Consider This Package
Consider it when:
- We are on, or already committed to, PHP 8.3 and Laravel 13 within the current planning horizon — the upgrade cost is then effectively zero.
- The capability is peripheral to the product's differentiation; consuming a maintained dependency is cheaper than owning one.
- We can accept a fast-follow support model, where our Laravel upgrade cadence matches the package's release cadence by policy rather than by aspiration.
- We want the modernized tooling baseline (Pint) and containerized dev environment, typically because we plan to contribute or maintain a fork.
Look elsewhere, or hold at a pinned tag, when:
- The product is pinned to Laravel 12 or earlier for twelve months or more — every future release of this package will be unavailable to us.
- We need vendor-backed support windows, security backports, or an SLA. "Latest major only" is structurally incompatible with LTS-style expectations, and no amount of pinning produces backports.
- The capability is core to the product and a silent loss of maintenance would be a business risk rather than a technical inconvenience.
- Compliance or procurement requires a maintained CI/QA attestation from the upstream project; Scrutinizer removal weakens that story.
How to Pitch It (Stakeholders)
For executives: A dependency we may use has shipped a major release that requires PHP 8.3 and Laravel 13, and its maintainer has moved to supporting only the newest Laravel version. The practical consequence is small and bounded — one upgrade, done alongside a Laravel upgrade we would need anyway — but it makes our Laravel upgrade cadence a product-risk input rather than a purely technical preference. If we fall a major version behind, we stop receiving fixes, including security fixes. Recommendation: adopt the release when we move to Laravel 13, and record a decision now on how long we are willing to run pinned and unsupported.
For engineering: Budget a single focused change: bump the constraint, move the runtime to PHP 8.3/13, apply Pint formatting, and remove any reliance on the package's former pre-push hook and Scrutinizer checks. Drop the local Podman tooling from scope unless we fork. The one thing worth flagging upward is the support-policy change — it means our upgrade lag is now a tracked risk, and we should be able to say what our maximum tolerated lag is.