Laravel Model Suspension Laravel Package

Product Decisions This Supports

• Platform upgrade planning / hard gating: v3.2.0 sets a floor at Laravel 11 and adds Laravel 12 support. Any roadmap item that assumes we remain on Laravel 10 is now blocked by this dependency — that constraint belongs in the plan, not in a surprise during implementation.
• Build vs buy: If our product is anchored on Laravel 10 with no near-term upgrade, staying on this package means pinning to v3.1.x and eventually owning a fork or a backport branch. That is a real, recurring maintenance cost to weigh against replacing the package outright.
• Roadmap sequencing: The framework upgrade and the package upgrade should be one workstream, not two. Bundling them reduces QA cycles and avoids a window where we are on Laravel 12 but an outdated package.
• Support matrix and customer commitments: If this package ships inside our product or to customers, our stated Laravel support policy is now partly determined by it. Sales and support need the updated floor (Laravel 11+) reflected in docs and contracts.
• Unblocking feature work: Anything that depends on Laravel 12-only capabilities becomes available to us only once we are on v3.2.0 or later. This release is the enabling precondition.
• Dependency risk signal: A release that tracks the framework's cadence this closely is a positive maintenance indicator — it argues for keeping the dependency rather than internalizing it.

When to Consider This Package

Adopt when:

• We are on Laravel 11 or 12, or are committed to Laravel 12 within the planning horizon.
• We want a dependency that follows Laravel's release cadence rather than lagging it; this release is a fast follow on Laravel 12 and a clean drop of Laravel 10.
• We are already on the 3.x line — v3.2.0 reads as a platform-support release rather than a feature or API-breaking release, so the upgrade itself should be low-effort on supported versions.

Look elsewhere, or defer, when:

• The product is anchored on Laravel 10 with no upgrade path this cycle. v3.2.0 is simply unavailable to us, and v3.1.x becomes a dead-end branch that will receive no further features and, likely, no security fixes.
• We need a longer support window than the upstream framework provides. This package appears to inherit Laravel's lifecycle, so it inherits the same annual upgrade pressure.
• The package is load-bearing and the team cannot absorb a framework-coupled upgrade every Laravel cycle. That is a staffing and architecture question, not a package-quality question.

Caveat: this assessment is based on release metadata only. The package's functional scope, test coverage, and maintainer responsiveness should be validated before committing, particularly if it is load-bearing for us.

How to Pitch It (Stakeholders)

For executives: This is a maintenance release that keeps the package aligned with the framework's support lifecycle. It is a positive maintenance signal — the vendor is keeping pace with Laravel 12 — which lowers our long-term dependency risk. The trade-off is that it forces our hand on Laravel 10: we can no longer stay on that version and receive updates. Recommendation is to fold the framework upgrade into the next planning cycle as a single scoped item, rather than funding a bespoke fork or backport branch that we would then own indefinitely.

For engineering: v3.2.0 drops Laravel 10 and adds Laravel 12. Treat it as breaking for any Laravel 10 consumer — pin v3.1.x if we must stay temporarily, but plan the exit, because that branch is now off the mainline. On Laravel 11 and 12 this should be a low-risk version bump with no indicated API changes. Concrete asks: add a Laravel 12 entry to the CI matrix, remove Laravel 10 once the cutover lands, and confirm in the upgrade ticket that no application code depends on behavior specific to the dropped version.