Laravel Starter Kit React Laravel Package

Product Decisions This Supports

• Runtime/platform roadmap: v1.3.0 raises the minimum PHP version to 8.5. That is the single most decision-relevant fact in this release: it converts the package from "installable on our current stack" into a gated dependency tied to a PHP upgrade we may not have scheduled. Treat this as an input to the platform-upgrade business case, not a routine patch.
• Build vs. buy / build vs. adopt: a package that tracks the newest PHP release is actively maintained, which strengthens the "adopt" case over building in-house — but only if our own infrastructure can meet the new floor. If we cannot, the honest comparison shifts from "adopt vs. build" to "adopt-and-upgrade-PHP vs. pin-and-fork vs. build."
• Roadmap sequencing: the PHP 8.5 floor imposes an ordering constraint. Any feature work depending on this package inherits a prerequisite (PHP 8.5 in dev, CI, staging, production, and any managed hosting or serverless runtime). Surface that dependency before committing dates.
• Feature / use-case fit: this release adds no new capabilities — it is a compatibility and maintenance change. It should not move the needle on product scope; it only affects when and whether we can ship.
• Risk register: a minor version number (1.3.0) carrying a runtime-floor bump is a semver signal worth noting. Consumers who pin loosely could pull a version their platform cannot run. Locking versions and reading the constraint diff before composer update becomes a standing release-hygiene item.

When to Consider This Package

Consider adoption when:

• Our application, CI images, and production runtime are already on PHP 8.5, or the PHP 8.5 upgrade is funded and scheduled inside the same planning horizon as this package's integration.
• We want a dependency whose maintainer is demonstrably keeping pace with the PHP release train — a fast floor bump is a credible maintenance signal.
• The package sits in a non-critical path where a version pin is an acceptable fallback if the runtime moves again.
• We have a lockfile discipline (committed composer.lock, constraint review in code review, dependency update PRs that show composer.json diffs).

Look elsewhere, or defer, when:

• Production runs PHP 8.2–8.4 with no upgrade path this quarter — an 8.5 floor is a hard blocker, not a warning.
• We depend on managed hosting, container base images, or a PaaS whose PHP 8.5 support lags the language release. Verify the host's timeline before committing; the package's release date is not our deploy date.
• We need long-term support on an older runtime for compliance or client-environment reasons; a package that raises its floor aggressively will keep re-breaking that constraint.
• The package is load-bearing and we cannot absorb an ecosystem-wide runtime jump on the maintainer's cadence.

Regardless of path: confirm what the upper bound of the constraint actually is (does it require PHP >=8.5, or >=8.5 <8.6?), whether a maintained branch still supports the prior PHP line, and whether the jump came with any deprecations that will surface as warnings now and errors later.

How to Pitch It (Stakeholders)

For executives: "A dependency we are evaluating just moved its minimum requirement to PHP 8.5. That is not a feature release — it is a platform commitment. Adopting it now means adopting the PHP 8.5 upgrade on the same timeline. The good news is that it signals an actively maintained component and reduces the case for building this ourselves. The decision I need is sequencing: fund the PHP 8.5 upgrade and take the package, or defer the package until the runtime catches up. Either way the cost is the same upgrade — the only question is whether we do it on our schedule or the maintainer's."

For engineering: "v1.3.0 bumps the PHP floor to 8.5 with no functional changes. Concretely that means: CI matrix, Docker base images, local dev, and production all need 8.5 before we can bump this dependency; and anyone running composer update without reading the constraint diff will break their environment. Please (1) verify the exact constraint bounds and whether a prior-PHP support branch exists, (2) check our host's PHP 8.5 availability date, (3) land the PHP upgrade ahead of the package bump, not after, and (4) pin the current working version in the meantime so loose constraints don't pull it early. Also scan for deprecation notices the new floor may introduce — those tend to become errors two releases later."

One-line summary for a roadmap doc: "Maintenance-only release; the PHP 8.5 floor is a scheduling dependency, not a capability gain — approve on platform readiness, not on features."