Resonate Users Laravel Package

Product Decisions This Supports

• Build vs. buy / adopt vs. defer: The jump to 1.0.0 is the decision-relevant event. A 1.x release is a public commitment to semantic versioning, which converts this from "evaluate in a spike" to "safe to depend on in a production roadmap." If this package was sitting in a backlog as a candidate dependency, the 1.0 milestone is the trigger to schedule the adoption decision rather than keep deferring it.
• Upgrade budgeting: The release explicitly states no API changes and points to UPGRADE.md. That means the migration cost is a dependency-constraint bump (webpatser/resonate ^0.7 → ^1.0), not a code rewrite. PM-relevant output: a low-effort, low-risk work item, not a story that needs design time.
• Dependency pinning policy: The package now tracks the core library's stable line (^1.0). That aligns the wrapper's release cadence with upstream majors and gives a predictable rule for future upgrades: a major bump here should be treated as a planned, scheduled change, not an incident.
• Roadmap confidence for dependent features: Anything on the roadmap that consumes this package can now be scoped against a stable contract. Feature commitments can be made without the "might break under us" caveat that a 0.x dependency forces into every estimate.
• Scope/feature freeze decision: Because there are no API changes between the last 0.x and 1.0.0, the functional surface is effectively unchanged. If earlier discovery concluded the package's capabilities were insufficient, 1.0 does not change that answer — stability is not the same as capability.

When to Consider This Package

• Consider it when: you already run webpatser/resonate or are evaluating it, you're on a supported Laravel/PHP version, you want the integration layer to carry a semver guarantee, and your team can absorb a major-version dependency bump in a normal sprint.
• You're a strong fit if: you've been holding off solely because the package was 0.x and you lacked a stability contract. That blocker is now removed.
• Look elsewhere / defer when: the decision was blocked on capability gaps rather than stability — 1.0 adds no features. Also defer if your application is pinned to constraints that prevent moving the core library to ^1.0, if you need vendor SLAs or commercial support, or if the supported Laravel/PHP matrix (not stated in these notes) doesn't cover your runtime — verify that before committing.
• Treat this as a follow-up, not a decision: this release is a maturity signal, not new evidence about fitness for purpose. The assessment remains thin on real capability and adoption data, so any production commitment should still be paired with a short validation spike and a read of UPGRADE.md.

How to Pitch It (Stakeholders)

To executives: The integration package we've been tracking has reached a stable 1.0 release and now tracks a stable 1.0 of its core library. That removes the main reason to keep deferring: we can build on it without the risk of breaking changes arriving unannounced. The upgrade itself is small — the maintainers confirm no API changes, so this is a version-constraint update, not rework. Recommendation: approve the dependency as a stable baseline and schedule the bump as routine maintenance.

To engineering: Bump the constraint on webpatser/resonate to ^1.0, follow UPGRADE.md, and run the full suite plus any integration tests that exercise this path. Because no API changes are declared, expected code churn is zero — but verify transitive dependency constraints and the supported Laravel/PHP matrix before merging, since those aren't specified in the release notes. Going forward, treat major bumps here as scheduled work: the 1.x line is our compatibility contract.