Laravel Model Suspension Laravel Package

Getting Started

v3.2.0 is a framework-compatibility release: it drops Laravel 10 support and adds Laravel 12 support. No package API or feature changes are described, so day-to-day usage should remain the same on supported Laravel versions.

• First check the package’s composer.json constraints for laravel/framework / illuminate/* and PHP.
• On Laravel 10: do not upgrade this package to ^3.2; stay on the latest 3.1.x line until the app is on Laravel 11 or 12.
• On Laravel 12: use ^3.2 and run your existing package workflows/tests after updating.
• On Laravel 11: verify compatibility explicitly—v3.2.0 removes Laravel 10 and adds Laravel 12, but the release notes do not spell out the full supported-version matrix.
• First use case: upgrade Laravel first, then update the package, then exercise the package’s primary app workflow to confirm no framework-integration regressions.

Implementation Patterns

Treat the package version as coupled to your Laravel version.

• Use a constraint such as:

  "require": {
    "vendor/package": "^3.2"
  }
  

• Keep CI matrix coverage explicit:
  • Laravel 10 + package 3.1.x
  • Laravel 11/12 + package 3.2.x
• Upgrade in stages: Laravel upgrade first, package update second, then application tests. This isolates framework-upgrade failures from package-update failures.
• For new Laravel 12 projects, start with ^3.2. For legacy Laravel 10 projects, pin to 3.1.x.
• Keep package usage behind app-level services, adapters, or config where practical. That limits blast radius if future releases change compatibility or internals.
• Avoid relying on undocumented Laravel framework internals; v3.2.0’s value is compatibility, not new public API surface.

Gotchas and Tips

• Composer resolution will fail on Laravel 10 if the package requires Laravel 11/12. Do not work around this with --ignore-platform-reqs; either upgrade Laravel or pin the package to 3.1.x.
• Use composer why-not vendor/package 3.2.0 to inspect blocking constraints.
• Check transitive dependencies and refresh composer.lock; a Laravel 12-compatible package can still be blocked by another dependency.
• If the package publishes config, migrations, or assets, compare published files after upgrade instead of blindly overwriting local changes.
• After upgrading, clear caches with php artisan optimize:clear and run the package’s relevant tests or smoke checks.
• Confirm the effective installed version with composer show vendor/package; the lockfile is the source of truth in deployed environments.
• Keep customizations in application config/code rather than vendor files so future compatibility releases remain low-friction.