App Stats Symfony Laravel Package

Product Decisions This Supports

• Build vs. buy for Laravel-native capability. A maintained package that tracks current PHP releases is the default "buy" answer for infrastructure-adjacent concerns (auth, queues, integrations, admin tooling) where the team's differentiation is elsewhere. The v2.0.0 PHP 8.1 baseline signals the maintainer is actively keeping the package inside Laravel's supported runtime envelope rather than letting it drift toward abandonment — a meaningful input when weighing a small internal build against a dependency.
• Platform upgrade sequencing. Because v2.0.0 raises the runtime floor to PHP 8.1, this release is a forcing function that couples the package roadmap to the platform roadmap. That makes it a scheduling dependency, not a feature ticket: any product milestone that depends on this package inherits the PHP 8.1 upgrade as a prerequisite.
• Support matrix and customer commitments. If the product is distributed (self-hosted, on-prem, agency-delivered), the package's minimum PHP version becomes a documented minimum for the product. That directly affects sales engineering, support SLAs, and any contractual language about supported environments.
• Security posture decisions. Dropping PHP 8.0 means dropping a runtime that is itself past end-of-life. Adopting this release aligns the dependency graph with patched runtimes — a decision that belongs in a security/risk review, not just a sprint.
• Roadmap timing for deprecation communication. A major version bump is the natural moment to publish a support window, sunset plan, and migration guide for downstream teams. That is a comms and program-management decision the PM owns.

When to Consider This Package

Adopt when:

• The runtime is already on PHP 8.1+, or the platform upgrade to 8.1+ is funded and scheduled. If the team cannot move off PHP 8.0 in the next one to two quarters, this release is not adoptable and pinning to v1.x becomes the deliberate, documented choice.
• The Laravel version in use is compatible with the package's supported range — verify against the package's own composer constraints rather than assuming Laravel and PHP version floors move together.
• The dependency is load-bearing for a shipped or near-shipped feature. A major bump is cheapest while the surface area of integration is small, i.e. before more code is written against v1.x APIs.
• There is a credible maintenance signal. The PHP 8.1 move is one such signal; confirm it is paired with recent Laravel-version support, responsive issue triage, and a tagged release history — a one-off bump after a long dormancy is a different risk profile.
• Licensing and governance clear review — check the license against distribution model (SaaS vs. redistributed source), and confirm no transitive dependency introduces a conflicting constraint on the PHP floor.

Look elsewhere when:

• The platform is pinned below PHP 8.1 by hosting, a legacy Laravel version, or a customer-controlled environment with no upgrade path in the planning horizon. Forking to backport support is almost never worth it for a non-differentiating package.
• The package's only recent activity is the runtime bump. If the PHP 8.1 change is the first release in a long time, treat v2.0.0 as a maintenance checkpoint, not evidence of an active roadmap.
• The capability is core to competitive differentiation, in which case the runtime-coupling risk of an external dependency outweighs the build cost.
• The upgrade cannot be validated cheaply — no test coverage around the integration points, no staging environment on 8.1, or no one available to own the migration.

How to Pitch It (Stakeholders)

For executives (one paragraph): The package we depend on has shipped a major version that raises its minimum runtime to PHP 8.1. This is an infrastructure alignment release rather than a feature release — it does not add product capability, it removes support for an older, end-of-life PHP runtime. Practically, it converts an optional platform upgrade into a scheduled one: our continued ability to take security fixes and improvements from this dependency now depends on our PHP version. The cost is an engineering migration we would have had to do anyway; the risk of deferring is accumulating unsupported runtime and a widening gap we eventually pay down under pressure. Recommendation: fund the PHP 8.1 upgrade as a planned platform item, pin to the previous major until it lands, and publish the resulting supported-environment baseline internally and to customers.

For engineering (summary): v2.0.0 is a breaking change: the PHP floor moves to 8.1. Treat this as a migration, not a patch — plan for a dependency bump, a CI matrix change to 8.1+ (and dropping 8.0 from the matrix), and a regression pass on every integration point. Confirm the package's Laravel compatibility constraints at the same time, since a PHP floor change and a framework floor change often land together. Freeze the current major in production, do the upgrade on a branch behind existing test coverage, and expand coverage first wherever our integration is thin — that is the cheapest insurance against a runtime-related surprise. Once merged, update the documented minimum environment and any deployment images or container bases in the same change so we don't split the source of truth.