Widgets Laravel Package

Product Decisions This Supports

• PHP 8 platform migration. v5.1.0 removes this package as a blocker for teams moving to PHP 8.x runtimes. That directly informs the "can we schedule the PHP upgrade this quarter?" decision — one fewer dependency to exception-list.
• Build vs. buy. A package that ships compatibility updates against a current major (v5) is signalling active maintenance. That weakens the case for forking or replacing it with in-house code, and strengthens the case for standardising on it.
• Roadmap sequencing. Once this package (and its remaining peers) declare PHP 8 support, the CI matrix can drop PHP 7.x jobs, and PHP 8-only language features (constructor promotion, named arguments, enums in 8.1, attributes) become usable in the feature roadmap rather than deferred.
• Feature-level unblocking. Any planned feature that would benefit from PHP 8 syntax or from PHP 8-only library versions is now unblocked with respect to this dependency, though still gated by the rest of the dependency graph.
• Use cases. Long-lived Laravel applications on the 8.x line, teams standardising developer environments on PHP 8, and products with a multi-year support horizon where runtime currency is a procurement/security requirement.

When to Consider This Package

Adopt when:

• You are on PHP 8.0+ and were previously held back by this package's compatibility range.
• You already depend on it and want to stay on the maintained major rather than pinning to an older line.
• Your roadmap depends on PHP 8 language features or on libraries that have themselves moved to PHP 8.

Look elsewhere / defer when:

• The claim is narrow. "Add PHP 8 support" at v5.1.0 most plausibly means PHP 8.0 compatibility declared in composer.json. Do not read it as PHP 8.2/8.3 readiness — verify the actual constraint and, ideally, the CI matrix before treating modern-PHP support as settled.
• You are still on PHP 7.4 and pinned there; the release is likely a no-op for you, and you should track the 7.x line's support window separately.
• Laravel framework version support is unaddressed here. A PHP 8 bump says nothing about Laravel 10/11 compatibility — confirm against your target framework version.
• You need guarantees this release does not provide: no deprecations, no removals, no security fix is announced, so nothing here changes a risk posture around those concerns.
• Single-maintainer or low-bus-factor risk matters to you; one compatibility commit is weak evidence of sustained stewardship.

Action before committing: treat this as a claims-level signal. Check composer.json require constraints, the test matrix, and whether PHP 8.0 is the floor or the ceiling.

How to Pitch It (Stakeholders)

For executives (one paragraph): Version 5.1.0 is a minor, non-breaking release that adds PHP 8 support. It does not change any behaviour, API, or data model, so there is no migration cost and no user-facing impact. Its value is strategic rather than functional: it removes a dependency-level obstacle to modernising our PHP runtime, which is the prerequisite for the security-patch cadence and hosting-options work already on the roadmap. Risk of upgrading is low; the main caution is that the release note is terse, so engineering should confirm the exact PHP version range rather than assuming full modern-PHP coverage.

For engineering (summary): Semver-minor release, additive compatibility only — no breaking changes, no deprecations, no upgrade steps beyond a composer update. Recommended actions: (1) bump the constraint and confirm the declared PHP range in composer.json; (2) add/verify PHP 8 coverage in CI before relying on it; (3) note that this does not by itself establish Laravel-version or PHP 8.2+ support, so keep those as separate line items. Treat the release as an enabling step, not as a completed platform upgrade.