Symfony Laravel Package

Product Decisions This Supports

• PHP 8.5 upgrade sequencing. This release is a compatibility-maintenance patch: it raises the floor to papi-core >= 0.15.3 specifically to inherit PHP 8.5 fixes. That makes it the artifact to cite when deciding when your application can move to PHP 8.5, and gives engineering a concrete, low-risk step to schedule ahead of the runtime upgrade rather than during it.
• Runtime lifecycle / technical-debt roadmap. If PHP 8.5 is on the platform roadmap for the next one to two quarters, adopting this version now avoids a forced, compressed upgrade later. Treat it as a cheap option on a future deadline.
• Dependency-floor decisions in your own composer.json. Because the fix lives upstream in papi-core, not in this package, the decision is really "do we accept a transitive minimum-version bump?" That is a governance question — useful input for a policy on whether the team pins transitive dependencies or lets the resolver float.
• Build vs. buy / build vs. adopt. Relevant only if you are evaluating this package as a component of a larger capability. The signal here is maintenance health (upstream tracking, timely PHP-version support), not feature surface.
• Release cadence expectations. A pre-1.0 package shipping patch releases that are purely dependency-floor bumps tells you the maintainers treat runtime currency as in-scope. That is a positive maintenance signal to weigh against the API-instability risk of a 0.x version line.
• Not supported by this release: any feature, UX, performance, or capability decision. There is no new surface area here, so it should not move a roadmap item on its own.

When to Consider This Package

Consider it when:

• You are on, or planning, PHP 8.5 and need dependencies that do not block the upgrade. This release is an explicit signal of readiness.
• You already depend on this package and papi-core, and want the smallest possible change to pick up upstream runtime fixes — the diff is a version constraint, not a behavior change, so regression risk is low.
• You are assembling a Laravel/PHP stack where maintenance responsiveness matters more than feature velocity — e.g. long-lived internal platforms, multi-year products.
• Your team is comfortable tracking a 0.x dependency and has a habit of reading upstream constraint changes before merging.

Look elsewhere, or defer, when:

• You need API stability guarantees. At 0.15.x, breaking changes are permitted in minor releases by semver convention; nothing here changes that.
• You are not planning a PHP 8.5 move in the foreseeable window. The release delivers no functional value to you, and pulling it in only adds churn and a wider transitive constraint surface.
• Your dependency policy forbids transitively raising minimum versions without a full audit — in which case treat this as an audit item, not a routine bump.
• You require a 1.0+ support commitment or LTS from vendors; this package does not offer one yet.
• The upstream papi-core project is not something you are willing to depend on directly — the coupling here means you inherit its release cadence and constraint decisions.

How to Pitch It (Stakeholders)

For executives (one line): A routine maintenance release that keeps this Laravel package compatible with the upcoming PHP 8.5 runtime — no new features, no breaking changes, low risk, and it protects us from a scramble later in the platform-upgrade cycle.

For engineering leadership: Version 0.15.1 is a patch that raises the minimum papi-core to 0.15.3 to inherit that project's PHP 8.5 fixes. There is no code-level change on our side — the work is a composer constraint resolution plus a standard regression pass. Two things to note: (1) the actual fix lives in the transitive dependency, so our exposure is to papi-core's quality and cadence, not just this package; (2) we remain on a pre-1.0 line, so minor versions can still break us and we should keep the lockfile pinned and reviewed.

Recommendation to state plainly: Approve the upgrade as a scheduled, low-priority maintenance item if PHP 8.5 is anywhere on the roadmap; if it is not, this can wait until the next routine dependency sweep. Either way, do not market it internally as a capability improvement — it is hygiene, and the honest framing keeps credibility with the engineers who will do the work.