Navigator Laravel Package

Product Decisions This Supports

• Framework upgrade planning. 3.0.0 is the release that unblocks Laravel 13 adoption. If Laravel 13 is on our roadmap, this package's upgrade is a hard dependency in that critical path, not a parallel workstream.
• Platform baseline decisions. The package now has a single supported platform: Laravel 13 on PHP 8.3+. Because it drops Laravel 12 and PHP 8.2 in the same release, our framework version and our PHP runtime version are now coupled — we cannot take one without the other.
• Build vs buy. A major release that tracks the framework's release cycle is a positive maintenance signal. It argues for continuing to buy rather than building or vendoring an in-house equivalent, provided we accept the vendor's cadence as our own.
• Roadmap sequencing and risk. Applications still on Laravel 12 / PHP 8.2 become pinned to the 2.x line, which will stop receiving fixes as Laravel 12 ages out. That is a technical-debt item with a deadline attached, and it deserves an owner and a date rather than a backlog slot.
• Use cases. Greenfield services on Laravel 13 should adopt 3.x immediately. Existing services should be triaged by current Laravel/PHP version into "upgrade now," "upgrade this quarter," and "blocked pending PHP runtime work."

When to Consider This Package

Consider adopting (or upgrading to) this release when:

• You are on, or are actively moving to, Laravel 13 and PHP 8.3+, and you want upstream fixes and security patches rather than a frozen dependency.
• You want framework currency maintained by someone else instead of owning a compatibility shim.
• Your CI matrix, static analysis baseline, and dependency constraints can be moved to PHP 8.3+ in the same change window.

Look elsewhere, or deliberately stay on 2.x, when:

• You are locked to PHP 8.2 or Laravel 12 by hosting, shared packages, or an internal platform team, with no credible upgrade date. Pinning 2.x is legitimate, but it must be a documented, time-boxed decision — not drift.
• Your organisation has a slow, infrequent upgrade cadence. This package moves with framework majors on the framework's schedule, which means it will periodically force your hand. A package with a broader support window may suit you better, even at some cost in freshness.
• The integration surface is small enough that maintaining a thin in-house adapter is genuinely cheaper than absorbing repeated majors.

Before committing, confirm two things the notes do not state: whether 3.0.0 carries breaking API changes beyond the platform-support drop (read the upgrade guide and full changelog — majors usually do), and whether all of your transitive dependencies already support Laravel 13. The risk in this release is less the stated change than the ecosystem readiness behind it.

How to Pitch It (Stakeholders)

For executives. This package has shipped a major release that adds support for Laravel 13 and drops Laravel 12 and PHP 8.2. The headline is favourable: the vendor is actively maintaining the package against current framework versions, which is what we pay for and what keeps us on patched, supported software. The cost is a coordinated upgrade — we move our PHP runtime and our framework version together, on the vendor's timetable rather than ours. The decision required is scheduling, not whether to adopt: remaining on the previous major means accepting an unsupported dependency over time. Recommend we fund the upgrade as a planned piece of work with a named owner and a target date.

For engineering. Treat 3.0.0 as a breaking change. Two version floors move at once — PHP 8.3 and Laravel 13 — so the upgrade is a single atomic change, not two independent ones. Plan for: verifying every transitive dependency supports Laravel 13 before starting; reading the upgrade guide for API changes beyond the stated support drop; updating the CI matrix and any static-analysis or linting baselines tied to PHP 8.2; and a regression pass over the package's integration points. If any service cannot reach PHP 8.3 in this window, pin it to 2.x explicitly and record the reason and the review date. Do not let 2.x pins accumulate silently — they convert a routine upgrade into an incident later.