Laravel Cacheable Laravel Package

Product Decisions This Supports

• Platform upgrade planning (Laravel 11 / PHP 8.3): This release removes a hard blocker for teams planning to move onto Laravel 11 or PHP 8.3. It directly supports the decision to schedule framework/runtime upgrades rather than defer them, and reduces the risk of a "stuck on Laravel 10" outcome in the roadmap.
• Build vs. buy: Continued maintenance across new Laravel and PHP versions is a strong signal that buying/adopting this package is cheaper than building and maintaining equivalent functionality in-house. Sustained compatibility work is the main thing a PM is actually paying for in a dependency.
• Runtime support policy (PHP 7.4 end-of-life): Dropping PHP 7.4 is a forcing function. It converts a vague "we should upgrade PHP someday" into a dated migration workstream with a clear owner and cost estimate.
• Risk and technical debt reduction: Dependency updates plus CI and test-suite modernization (PHP 8 attributes, PHPUnit config, GitHub Actions) reduce the probability of silent breakage in our CI and lower the long-term maintenance burden of the dependency.
• Scope/feature decisions: This is a maintenance and compatibility release — no new end-user capability. It should not be positioned as a feature delivery; it belongs in the "keep the lights on / platform health" bucket of the roadmap, not the customer-facing one.
• Sprint and resourcing decisions: Expect a small but real allocation for upgrade verification (CI matrix, staging soak, dependency lockfile refresh) even though the package itself requires no integration work.

When to Consider This Package

Adopt / stay on it when:

• You are on, or planning to move to, Laravel 11 and/or PHP 8.3 — this release is explicitly aligned with that target.
• You want a dependency that is actively tracking upstream framework and runtime releases rather than one that lags by a major version.
• Your own CI already runs on PHP 8.1+ and a modern PHPUnit, so the test-tooling changes are transparent to you.
• You value a maintainer who invests in CI and test hygiene — that is a leading indicator of future release quality.

Look elsewhere / pause when:

• You are still pinned to PHP 7.4. This release drops it, so adopting 1.12.0 will break your runtime. Stay on the last 7.4-compatible release (pin it explicitly) or treat the PHP upgrade as a prerequisite.
• You are on an older Laravel version that is not covered by the updated dependency constraints — verify the composer constraint range before upgrading.
• You need new functionality. Nothing here adds product capability; if you were waiting on features, keep waiting and evaluate alternatives on their feature merits.
• Your release process requires long-lived support for legacy runtimes. A package that drops EOL runtimes on a regular cadence may not match a slow-moving enterprise support window.

Before adopting, verify:

• The exact PHP and Laravel constraint ranges in composer.json for 1.12.0.
• Whether any transitive dependency bumps carry their own breaking changes.
• That the PHP 8 attribute conversion in tests is confined to the package's own suite and does not affect published/consumer-facing code.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a routine but important maintenance release for one of our Laravel dependencies. It adds support for Laravel 11 and PHP 8.3, and drops PHP 7.4, which has reached end of life upstream. There is no new customer-facing functionality and no direct cost. The strategic value is that it keeps our planned platform upgrade on the critical path rather than blocked, and it confirms the maintainer is actively investing in the package — reducing the long-term risk and cost of owning this part of our stack. The one action item is confirming we are off PHP 7.4 before we upgrade; if we are not, that upgrade becomes a prerequisite and should be scheduled.

For engineering leads:

• Adopt 1.12.0 as part of the Laravel 11 / PHP 8.3 upgrade workstream — no separate project needed.
• Breaking change to plan around: PHP 7.4 support is dropped. Audit any service, queue worker, or CI image still on 7.4; pin the previous release if you cannot move immediately.
• Dependency constraints have moved — re-run composer update in a branch and review the lockfile diff rather than assuming a drop-in.
• The package's test suite, PHPUnit config, and GitHub Actions workflows were modernized (doc-comment metadata replaced with PHP 8 attributes). This is internal to the package, but it's a reasonable pattern to mirror in our own suites during the upgrade.
• Estimated effort: low. Expect verification and staging soak time, not integration work. No API or behavioral changes are signalled in these notes — confirm against the changelog before closing the ticket.