Laravel Paket Laravel Package

Product Decisions This Supports

• Unblocks a platform upgrade, not a feature. Release 1.9.0 adds PHP 8 support. For a PM this is a dependency/roadmap decision rather than a product decision: it converts "we cannot move to PHP 8 while we depend on this package" into "we can." That directly affects migration sequencing, not the customer-facing roadmap.
• Build vs. buy signal. A package that tracks new PHP runtimes is being actively maintained. That lowers the estimated total cost of ownership versus in-house code and reduces the "will we be stranded on an old runtime" risk premium in the buy case.
• Use cases it enables. Any initiative gated behind a PHP 8 migration — performance work, security/compliance deadlines tied to PHP 7.4 end-of-life, or adoption of newer Laravel versions that require PHP 8.
• What it does not do. There are no new product capabilities here. No roadmap reprioritization, no user-facing change, no demo material. Treat this as infrastructure hygiene and scope it into the platform workstream, not the product backlog.

When to Consider This Package

Adopt when:

• You are on Laravel and intend to run PHP 8 in the near term; this release is the minimum bar you should require from any dependency.
• You want dependencies that keep pace with runtime upgrades so future PHP/Laravel bumps are routine rather than projects.
• The package's existing surface area already matches your need — this release adds compatibility, not scope, so evaluate fit on the prior feature set.

Look elsewhere or defer when:

• You are staying on PHP 7.x for the foreseeable future; 1.9.0 delivers no benefit until the runtime upgrade is actually scheduled.
• You need functionality outside the package's scope — nothing in this release expands capability.
• Verify before committing: a single line in the changelog does not prove the package is tested on PHP 8. Confirm CI runs the suite against PHP 8 (not just a widened composer.json constraint), check whether the PHP 8 work is covered by the maintainer or a one-off community PR (#84), and check release cadence and maintainer count. Thin evidence of ongoing maintenance is the main reason to prefer an alternative.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk compatibility release — not a product change. Its value is that it removes a blocker to our PHP 8 upgrade, which protects us from end-of-life security exposure and avoids paying for a custom fork or workaround. Cost is a version bump and a regression test pass; the payoff is schedule, not features. Recommendation: approve the upgrade as part of the platform workstream, contingent on confirming the dependency is genuinely tested on PHP 8.

For engineering: Version 1.9.0 adds PHP 8 support (PR #84). Please (1) confirm the test suite actually runs green on PHP 8 in CI, (2) pin the version and run our own integration tests against it, and (3) sequence the bump with the broader runtime upgrade rather than ahead of it. Flag immediately if the change is only a widened Composer constraint without test coverage — that changes the risk profile and we should treat it as unproven.