Plan Craft Laravel Package

Product Decisions This Supports

• Upgrade sequencing and platform budget. v2.0.0 raises the floor to PHP 8.3+ and adds Laravel 13 support, which makes this package a forcing function for a PHP runtime upgrade. That is a roadmap input, not just a dependency bump — it should be scheduled against the wider Laravel 13 migration, not discovered mid-sprint.
• Build vs. buy, re-validated. A major version that tracks a new Laravel major plus current Testbench/Pest tooling is evidence of active maintenance. That strengthens the case for keeping this as a bought dependency rather than absorbing maintenance in-house — the maintainer is paying the ecosystem-churn tax for you.
• Vendor and dependency risk tracking. Semver-major means possible breaking API changes beyond the platform floor. Treat this as a "read the changelog before merging" item, and use it as a prompt to confirm the package has a credible release cadence and a maintainer who ships on framework day one.
• CI and tooling modernization. The Testbench v11 / Pest v4 alignment is a dev-only signal, but it matters to engineering: it tells you the project's test harness is current, which lowers the cost of contributing patches or forking if you ever need to.
• Use-case fit. Whatever surface this package covers, it is now only viable in product decisions where PHP 8.3+ is already true or planned. Any roadmap item that assumes an older runtime cannot depend on v2.x.

When to Consider This Package

Adopt when:

• Your platform baseline is PHP 8.3+ today, or a runtime upgrade is already on the near-term roadmap.
• You are moving to Laravel 13 (or plan to within the support window) and want dependencies that are current on day one rather than lagging a quarter behind.
• You want a maintained dependency over an internally owned equivalent — the release signals a maintainer who tracks framework majors promptly.
• Your CI can run Pest v4 / Testbench v11, or you can isolate the package's own test suite from your application's.

Look elsewhere, or pin to the prior major, when:

• You are contractually or infrastructurally stuck on PHP 8.2 or lower — managed hosting, legacy shared environments, or an app with other dependencies that block the runtime bump. In that case stay on the last 1.x line and track its support status explicitly.
• You are on Laravel 12 and have no near-term 13 migration; a major version jump here buys you little and adds migration surface.
• You need a stable API contract for a long horizon and cannot absorb a semver-major review cycle. Validate the diff between 1.x and 2.0.0 before committing — the release note describes platform support, not the full set of behavior changes.
• The package sits on a critical path and has no fallback. Single-maintainer risk is unchanged by a compatibility release.

How to Pitch It (Stakeholders)

To executives: This is a maintenance release that keeps a dependency aligned with the current Laravel and PHP generations. The cost is not the package — it is the PHP 8.3 runtime upgrade it implies, which we should fold into the Laravel 13 migration we are already planning rather than treat as a separate project. The benefit is that we continue to externalize maintenance of this capability instead of staffing it internally, and we avoid being stranded on an unsupported framework line.

To engineering: v2.0.0 requires PHP 8.3+, adds Laravel 13 support, and moves its dev dependencies to Testbench v11 and Pest v4. It is a semver-major, so review the full changelog for API breaks beyond the platform floor before upgrading. Recommended sequence: bump runtime in CI first, run the suite against 2.0.0 in a branch, then merge behind the framework upgrade. Confirm the 1.x support window so we know our fallback if the runtime bump slips.

Caveat for both: this assessment is based on release metadata only. Prior to commitment, confirm the concrete breaking changes in the 1.x → 2.0.0 diff and the maintainer's stated support policy for the previous major.