Samsa Laravel Package

Technical Evaluation

Architecture fit

• Samsa remains a conventional Composer package for Laravel applications; the 1.4.0 change is a platform floor bump, not an architectural rework. No new runtime dependencies, service providers, or infrastructure components are introduced.
• The package's coupling is now explicitly to the Laravel 13 lifecycle. That aligns the package with the newest framework major but narrows the set of applications where it can be installed without also upgrading Laravel.
• The continued, CI-enforced siberfx/message-bus integration confirms async/messaging remains a supported topology rather than an afterthought, which is relevant if the surrounding system is event-driven.

Integration feasibility

• Feasible only on PHP 8.3+ and Laravel 13. Any service still on PHP 8.2 or Laravel 12 cannot take 1.4.0 and is pinned to 1.3.x by Composer's constraint resolution — this is a clean, automatic fallback, not a silent breakage.
• Because the previous major (Laravel 12) is dropped rather than supported in parallel, this is a hard cutover per service: upgrading Samsa forces the Laravel 13 upgrade to land first or in the same change.

Technical risk

• Medium. The direct code risk of the package change is low (dependency floor bump), but it acts as a forcing function for a framework major upgrade — the real risk sits in the Laravel 12 → 13 migration of the host application, not in Samsa.
• Risk is concentrated in services with long-tail dependencies that block Laravel 13. Those services are frozen on 1.3.x, which becomes a maintenance branch we do not control.
• Test-tooling shifts (Testbench 11, PHPUnit 12) matter only for our own test suite if we extend or mock package internals; they are a signal that 1.3.x and 1.4.x have divergent test harnesses.

Key questions

• What is the support window for Samsa 1.3.x — security fixes only, or bug fixes too? For how long?
• Is Laravel 13 a hard requirement of the package's own code, or a conservative CI matrix choice? (Affects whether a 1.4.x patch could restore 12 support.)
• What is the package's release cadence and how often has it dropped framework majors historically?
• Does siberfx/message-bus have a matching version constraint that must move in lockstep with Samsa 1.4.0?
• Are there behavioural changes hidden behind the "development tooling" bullet, or is runtime code unchanged from 1.3.x?

Integration Approach

Stack fit

• Fit is binary: Laravel 13 / PHP 8.3+ services are in scope; everything else is out. There is no partial-adoption path within a single application.
• Confirm the runtime PHP floor (8.3) is already met by our base images and CI runners — that is usually the cheaper half of the prerequisite and can be sequenced independently of the Laravel upgrade.

Migration path

• Inventory every service and package that depends on Samsa, and record its current PHP and Laravel version. This produces the in-scope vs. frozen-on-1.3.x split.
• For in-scope services: upgrade Laravel to 13 and PHP to 8.3 first, verify the application, then bump Samsa to ^1.4. Avoid doing both in one commit where possible so failures are attributable.
• For frozen services: pin explicitly to ^1.3 in composer.json rather than relying on resolution, so a future transitive change cannot surprise us, and record the pin as technical debt with an owner.

Compatibility

• Expect no backward-compatibility shim. Treat 1.4.0 as a coordinated upgrade with the framework, not an independent dependency bump.
• Verify the siberfx/message-bus version constraint resolves together with Samsa 1.4.0 in a scratch branch before planning the rollout; a lockstep constraint would couple two upgrade schedules.
• Check our own test suite for direct use of Orchestra Testbench or PHPUnit APIs that Samsa's harness now targets — only relevant if we subclass or extend package test utilities.

Sequencing

1. Publish the dependency inventory and the in-scope/frozen split.
2. Upgrade PHP to 8.3 in base images and CI (low risk, unblocks later work).
3. Pilot Laravel 13 + Samsa 1.4.0 on one low-traffic service; measure effort.
4. Roll out per service, highest-value first; keep 1.3.x pins on the remainder.
5. Set a review date tied to the vendor's 1.3.x support commitment.

Operational Impact

Maintenance

• Two supported Samsa lines now exist inside our estate. That is a temporary but real increase in maintenance surface — two versions in the dependency graph, two sets of upgrade notes to track.
• Budget ongoing effort for the 1.3.x tail; it will not receive the vendor's framework-compatibility work and will drift further from Laravel releases.

Support

• Upstream support for 1.3.x is the single largest unknown. If it is security-only or time-boxed, the frozen services carry an expiry date we must plan against.
• Internal support burden rises modestly: on-call and platform engineers need to know which services are on which line before triaging dependency-related incidents.

Scaling

• No scaling implications from the change itself — no new runtime components, queues, or network hops. Scaling characteristics of 1.3.x and 1.4.0 should be identical.
• The message-bus integration being CI-tested every job is a positive signal for throughput-sensitive, event-driven deployments.

Failure modes

• Install failure on frozen services: a stray ^1.4 constraint or a transitive requirement pulls the package forward and breaks the build. Mitigation: explicit pins and a CI check on the resolved version.
• Half-migrated service: Laravel 13 landed but Samsa stayed at 1.3.x, or vice versa, producing an unsupported combination. Mitigation: treat the pair as one atomic unit in the upgrade checklist.
• Silent behavioural drift: if 1.3.x and 1.4.0 diverge in runtime behaviour (not just tooling), services on different lines behave differently in production. Mitigation: confirm with the vendor whether runtime code changed; if unclear, assume it did.
• Lockstep constraint with siberfx/message-bus: an unresolvable pair blocks the upgrade entirely. Mitigation: test resolution early, before committing to a schedule.

Ramp-up

• Low for engineers: the package API is unchanged, so ramp-up is dominated by the Laravel 12 → 13 migration, which is familiar ground.
• Higher for platform/DevEx: someone must own the version inventory, the pin policy, and the 1.3.x expiry tracking. Assign that owner before the rollout begins.

Note: this assessment is derived solely from the v1.4.0 release notes; no prior assessment or repository data was available. Items marked as questions should be confirmed with the vendor before committing to a timeline.