Samsa Laravel Package

Product Decisions This Supports

• Build vs. buy for messaging plumbing. Samsa sits in the layer between application code and a message/event transport, with a tested integration against siberfx/message-bus. The decision this supports is whether to own that adapter/abstraction in-house or take a dependency — relevant anywhere the roadmap includes domain events, async workflows, or service-to-service messaging on Laravel.
• Upgrade sequencing on the platform roadmap. v1.4.0 hard-couples the package to PHP 8.3+ and Laravel 13. Adopting it is not an isolated composer bump; it is a commitment that the consuming application is on (or moving to) Laravel 13. This directly informs when the framework upgrade lands relative to feature work, and whether the messaging workstream is a blocker or a follower.
• Support-window and pinning policy. The maintainer kept 1.3.x available and let Composer hold older projects there rather than forcing a breaking upgrade. That supports a deliberate decision to pin ^1.3 for the current cycle and schedule the jump to 1.4 with the Laravel 13 migration, instead of splitting focus.
• Dependency-risk register entry. A single-maintainer package that gates on the newest framework major is a schedule-coupling risk: your messaging layer's upgrade cadence is now inherited from Laravel's. Worth recording explicitly if messaging is on a critical path.
• Quality/CI signal for the "is this safe to depend on" question. v1.4.0 shows the integration is exercised in every CI job against Testbench 11 / PHPUnit 12, not just a smoke job. That is a concrete, checkable maturity signal to weigh against alternatives.

When to Consider This Package

Consider it when:

• The application is already on, or actively migrating to, Laravel 13 and PHP 8.3+; adopting earlier is not possible on this line.
• You want a thin, framework-native abstraction over messaging rather than a full event-sourcing or broker-management platform; the package's value is fit with the framework, not breadth.
• siberfx/message-bus (or a comparable bus) is in or near your stack — that integration being tested in CI is the strongest evidence of intended use.
• You value predictable semver and a maintained prior line: 1.3.x staying installable means you can defer the upgrade without forking.
• The messaging surface you need is small and stable — the kind of thing you'd otherwise hand-roll in a service provider and regret.

Look elsewhere when:

• You are on Laravel 12 / PHP 8.2 and do not control the upgrade timeline. Stay on 1.3.x, but understand you are on a maintenance line, not the active one — plan the exit.
• You need guaranteed long-term support, an SLA, or a security-response commitment. The versioning here is considerate but community-cadence.
• Your requirements are throughput, delivery guarantees, ordering, or replay at a level that belongs in the broker/infrastructure decision, not a Laravel adapter.
• You need multi-framework portability; this is deliberately Laravel-shaped and now tied to a specific major.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost dependency that keeps our messaging code thin and framework-native instead of custom-maintained. The v1.4.0 release is a platform-currency release, not a feature release — it requires PHP 8.3 and Laravel 13, which means the real cost of adopting it is the framework upgrade we already have on the roadmap, not the package itself. The maintainer has kept the previous line installable, so there is no forced migration and no fork risk. Recommendation: pin the current line, adopt 1.4 alongside the Laravel 13 upgrade, and treat it as part of that workstream's budget rather than a separate line item.

For engineering: v1.4.0 is a clean breaking boundary — PHP 8.3+, Laravel 13, Testbench 11, PHPUnit 12. Composer will hold anyone on PHP 8.2/Laravel 12 at 1.3.x automatically, so the upgrade is opt-in per project and safe to stage repo by repo. The siberfx/message-bus integration is now exercised in every CI job, so the integration path we'd rely on is covered rather than assumed. Test surface has moved to the current major, which means 1.4.x is where fixes will land — 1.3.x is a valid holding position but not a permanent one. Plan the bump as the last step of the Laravel 13 migration, not the first.