Laravel Beekeeper Laravel Package

Product Decisions This Supports

• Coupled upgrade train: v13.0.0 requires PHP 8.4/8.5 and Laravel 13, and drops PHP 8.2/8.3 and Laravel 12. This is one initiative, not three tickets — runtime, framework, and package must move together. Plan and staff it as a single workstream.
• Dependency freeze / release-window planning: until that workstream is funded, pin to the v12 line and treat v13 as unavailable rather than "nice to have."
• Build vs buy: the package now tracks Laravel major-for-major (vN ↔ Laravel N). That predictability is a buy-positive signal — but it also means your upgrade cadence is now coupled to Laravel's, with no dual-support escape hatch.
• Support matrix for downstream artifacts: internal starter kits, client SDKs, and private packages built on this must publish a matching floor of Laravel 13 / PHP 8.4+.
• Roadmap gating: features depending on Laravel 13-only APIs are unblocked; anything committed against Laravel 12 is now stranded on a previous-major fork.
• Use cases: greenfield Laravel 13 services adopt immediately; legacy fleets stay on v12 and need a documented end-of-support date and exit criteria.

When to Consider This Package

Adopt when:

• You are greenfield, or already have Laravel 13 + PHP 8.4/8.5 on the roadmap and can absorb the upgrade in one cycle.
• Your deploy targets (containers, managed runtimes, CI matrix) already expose PHP 8.4.
• You need a maintainer who actively tracks the framework's major cadence and want that cadence reflected in your own support policy.

Look elsewhere or defer when:

• You are on Laravel 12 or PHP 8.2/8.3 with no upgrade mandate — v13 is a hard blocker with no graceful degradation and no dual-support window.
• You must run a single codebase across Laravel 12 and 13; v13 explicitly forbids it, so you'd need a version fork or an abstraction layer (its own cost).
• You have long certification or change-control cycles (regulated, embedded, on-prem) where a major-version cliff is untenable.
• Your hosting is shared/managed and lags on PHP minor releases.

How to Pitch It (Stakeholders)

For executives: this package now follows Laravel major-for-major, so our upgrade calendar becomes predictable — but v13 is a forced march. It requires PHP 8.4+ and Laravel 13 and drops PHP 8.2/8.3 and Laravel 12 outright, with no partial-adoption path. Fund the PHP runtime upgrade, the framework upgrade, and this package bump as one workstream, and place a dependency freeze on the current major until it is greenlit.

For engineering: pin to the v12 line until a Laravel 13 branch exists. Before committing to a date, verify three things: CI covers PHP 8.4/8.5, transitive dependencies declare the same floor, and deploy targets actually ship 8.4+. Then estimate real migration cost against our codebase rather than the release note.

Confidence caveat: this assessment is derived from the v13.0.0 release notes alone — there is no prior assessment and no usage telemetry behind it. Treat the adoption-cost estimate as unvalidated until engineering has done a spike against our code.