Mcx Info Symfony Laravel Package

Product Decisions This Supports

• Platform modernization roadmap: v3.0.0 raises the minimum runtime to PHP 8.1. For a PM this is a forcing function — adopting the release ties the package to your PHP upgrade timeline and to a Laravel version that supports PHP 8.1 (Laravel 9+). Treat the release as a milestone in the PHP 8.1+ migration plan rather than an isolated dependency bump.
• Build vs. buy: The PHP 8.1 floor reduces the maintenance surface the package owner has to support (one runtime branch instead of several) and is a signal the maintainer is actively investing in the package. That is a point in favor of buying/consuming rather than building equivalent functionality in-house.
• Feature and scope decisions: Because v3.0.0 is a compatibility release rather than a feature release, it does not unlock new user-facing capability. Do not plan roadmap items that depend on new package features in this cycle; budget the release as technical debt / platform hygiene work.
• Release planning and delivery risk: This is a semver-major bump, so it is a breaking change by contract even though the changelog is one line. Any service still on PHP 8.0 or below cannot adopt it, and any transitive dependency pinning an older major must be resolved first. Scope a spike before committing to a delivery date.
• Vendor and lifecycle risk: PHP 8.0 reached end of life in November 2023 and PHP 8.1 is in security-only support, so a maintainer moving to an 8.1 baseline is aligning with the supported-runtime floor. Use this as evidence the package is being maintained, and as a prompt to confirm the maintainer's stated support window for 8.1 versus 8.2/8.3.
• Prioritization input: Weigh the upgrade against other platform work using the same criteria as any infrastructure change — security exposure of staying on an older runtime, engineering hours to upgrade, blast radius across services, and whether it blocks other planned work.

When to Consider This Package

Consider adopting or upgrading when:

• Your application already runs PHP 8.1 or later, or the PHP upgrade is already funded and scheduled. Adoption then becomes low-cost and mostly a dependency-constraint exercise.
• Your Laravel version is one that supports PHP 8.1 (Laravel 9 and later). Verify framework compatibility explicitly rather than inferring it from the PHP constraint.
• You are standardizing dependencies on a single supported runtime and want packages whose minimum version matches your platform floor, reducing the matrix you test against.
• You need evidence of active maintenance for a vendor or dependency review — a major release driven by runtime support is a reasonable (if thin) maintenance signal, though it is not on its own sufficient.
• CI, local dev, and container images can be moved in the same change window. If they cannot, the upgrade will stall at the pipeline layer rather than the application layer.

Look elsewhere or defer when:

• You are locked to PHP 8.0 or earlier, or to a Laravel version that cannot run on 8.1. Staying on the previous major is the pragmatic answer until the platform moves.
• The one-line changelog is the only information available and you cannot inspect the actual diff, upgrade guide, or test coverage. A major version with a minimal release note carries unquantified regression risk; require the maintainer's upgrade notes before committing.
• You need documented new capability to justify the work. This release supplies compatibility, not features; if the business case depends on functionality, this release does not make it.
• The package is load-bearing for revenue-critical paths and there is no rollback plan. Major-version adoption on critical paths should be staged, not bundled into a feature release.
• Support posture matters more than version currency — confirm the maintainer's policy for 8.1 versus 8.2/8.3 and the expected cadence, since a package that just moved to a security-only runtime may move again soon.

How to Pitch It (Stakeholders)

For executives: A dependency we rely on has shipped a major version whose headline change is a minimum PHP 8.1 requirement. It does not add user-facing features and does not, by itself, change what we can build. It is a platform-alignment item: it keeps the package on a supported PHP runtime and gives us a maintenance signal on the vendor. The decision required is not "should we adopt this" but "when does our PHP 8.1+ migration happen," because this release is gated on that answer. Cost is engineering time, not licensing; risk is contained to deployment environments still below 8.1 and is mitigated by staged rollout. Recommendation: treat it as scheduled technical work attached to the existing PHP upgrade, not a standalone initiative.

For engineering: v3.0.0 is a semver-major release on a PHP 8.1 baseline. Audit the diff and any upgrade guide before merging — a one-line changelog does not establish that behavior is unchanged. Sequence the work as: confirm Laravel version supports PHP 8.1; move CI images and local/dev containers to 8.1 first; resolve transitive constraints blocking the major bump; run the full test suite against the new major; then roll out service by service with a rollback path. Flag any service pinned to PHP 8.0 as out of scope until its runtime upgrade lands. Note that 8.1 is in security-only support, so agree internally on whether to target 8.1 as an intermediate step or go directly to 8.2/8.3 to avoid a second migration in the same cycle.