Laraflash Laravel Package

Product Decisions This Supports

• Platform upgrade sequencing. v6.0.0 moves the supported baseline to Laravel 10 / PHP 8.2 and drops Laravel 9 / PHP 8.0. Adopting it is therefore coupled to our framework upgrade roadmap — this is a "when do we move the app to Laravel 10" decision, not a routine dependency bump.
• Build vs buy. The package shipped Laravel 10 and PHP 8.2 support in the same release that dropped the prior majors — evidence the maintainers track upstream promptly. That is a point in favor of buying/maintaining rather than building in-house.
• Roadmap gating. If we stay on Laravel 9 or PHP 8.0, v6 is a hard gate: pin to the last 5.x and accept a frozen support window with a known EOL, or upgrade the platform. Feature work that depends on PHP 8.2 language features or Laravel 10 APIs is blocked behind this decision if the package is a dependency.
• Risk tracking. The 5.x line becomes maintenance-only. That date should be an explicit, owned risk item rather than an implicit assumption.

When to Consider This Package

Adopt / upgrade to 6.0.0 when:

• The application is already on Laravel 10 and PHP 8.2, or is scheduled to be within the remaining support window of the 5.x line.
• You want a dependency whose maintainers ship new framework-major support promptly — a reasonable proxy for long-term viability.
• The build-vs-buy tiebreaker is "will this still be maintained through the next two Laravel majors?" This release is direct evidence for that question.

Look elsewhere or defer when:

• You are on Laravel 9 or PHP 8.0 with no near-term upgrade path. There is no in-place migration; 6.0.0 is a break, and the 5.x branch is now a dead end.
• You need support commitments longer than the vendor's demonstrated cadence.
• The package's core value overlaps with first-party Laravel functionality — re-run the build-vs-buy check at each major, since framework upgrades can absorb the use case.
• You are expecting functionality. 6.0.0 is a support-matrix release; there is no functional reason to upgrade on its own.

How to Pitch It (Stakeholders)

For executives: v6.0.0 is a maintenance release, not a feature release. The only change is the support matrix — it now targets Laravel 10 and PHP 8.2 and no longer supports Laravel 9 or PHP 8.0. The decision is purely about timing: we either fold this into our Laravel 10 upgrade, or we stay on the previous major and carry dependency-pinning risk. No new capability, no new spend, but it does tie our platform timeline to the vendor's release cadence.

For engineering: treat 6.0.0 as a breaking change driven entirely by the support matrix. The app must be on Laravel 10 and PHP 8.2 before this can land — there is no path from Laravel 9. Check the CI matrix, composer constraints, and any transitive dependencies still pinned to PHP 8.0. If the platform can't move yet, pin to the latest 5.x and log the EOL date as a tracked risk with an owner.