Laravel Web Push Laravel Package

Product Decisions This Supports

• Platform upgrade planning (PHP 7.x → PHP 8): Release 1.1.0 explicitly supports and tests against PHP 8 and ships upgraded Laravel 8 dependencies. This is the primary decision this release unlocks — if your roadmap includes a PHP 8 or Laravel 8 migration this quarter, this package is now a viable dependency rather than a blocker.
• Build vs. buy / build vs. adopt: The package's compatibility with the Laravel 8 + PHP 8 baseline lets you adopt it instead of writing and maintaining equivalent in-house code. Factor in that you would otherwise own the upgrade treadmill yourself.
• Dependency risk review for existing products: If the package is already in the stack, this release converts a "stale, unsupported dependency" risk item into a "maintained dependency" item on the technical-debt register — worth reflecting in roadmap confidence and security-review conversations.
• Feature/use-case fit cannot be judged from this release alone. The notes only describe platform support and tooling. Treat 1.1.0 as evidence of maintenance health, not as evidence of functional fit; validate use cases against the package's feature documentation.
• Release-gating decision: Adding GitHub Actions means the project now has automated CI. That supports a policy of requiring green CI before adopting or bumping a dependency, which is a cheap, defensible governance rule for the team.

When to Consider This Package

Adopt when:

• Your application targets PHP 8 and Laravel 8 (or is migrating to them) and you need a dependency that has been tested on that combination.
• You want a maintained dependency: versioned release, active compatibility work, and now automated CI.
• Your team's policy is to avoid dependencies that lag a major framework release — this package now tracks the current major Laravel line.
• You are consolidating onto a supportable baseline and want to reduce the number of components pinned to end-of-life runtimes.

Look elsewhere or defer when:

• You still run PHP 7.1 or 7.2. This release drops support for both, and it is a hard breaking change for those environments. Upgrading the package without upgrading PHP will fail; either pin to the prior 1.0.x line or schedule the PHP upgrade first.
• You are on Laravel 9+ or PHP 8.1+ — the notes stop at Laravel 8/PHP 8 and do not state forward compatibility. Confirm before assuming support.
• You need documented functional capabilities to make a decision. This changelog contains no feature, API, or behavioural information; run a proper feature evaluation first.
• The package is low-value relative to its surface area — a small utility you could own in a few hundred lines may cost less in long-term upgrade coordination than an external dependency.

Adoption checklist for the decision record: confirm the exact PHP and Laravel version matrix, note the 7.1/7.2 drop as a breaking change, verify CI status on the release tag, and confirm a maintained 1.0.x branch exists if you must stay on old runtimes.

How to Pitch It (Stakeholders)

For executives (one paragraph): The vendor behind this Laravel package has shipped release 1.1.0, which brings it onto current PHP 8 and Laravel 8 — the same baseline our platform roadmap is targeting. Practically, this removes a compatibility risk from our dependency portfolio rather than adding one: the component is now supported on the runtime we plan to standardise on, and the project has added automated testing, which lowers the odds of nasty surprises in future updates. There is one caveat: the release drops support for PHP 7.1 and 7.2, so any application we still run on those versions must either stay pinned to the previous line or be upgraded on schedule. No functional changes are involved, so product behaviour is unaffected; this is a maintenance and risk decision, not a feature decision.

For engineering: Version 1.1.0 is a support-matrix release — PHP 8 support and testing, Laravel 8 dependency upgrades, GitHub Actions CI added, PHP 7.1/7.2 dropped. Treat the runtime drop as a breaking change: inventory which services are on 7.1/7.2 before bumping, and pin to 1.0.x where the platform upgrade isn't yet funded. Because CI now exists, gate the bump on a green build in our own test suite as well as upstream. Note that the changelog carries no functional or API detail — pair this with a short feature-fit review before we commit to it for new work, and ask upstream to confirm the supported matrix beyond Laravel 8/PHP 8 if we intend to move to Laravel 9+.