Cmi Payment Laravel Package

Getting Started

Version 1.1.0 is primarily a Laravel compatibility release: it adds Laravel 11 support and drops Laravel 9 support. There is no package-specific feature API called out in the release notes, so the first step is validating framework compatibility before adopting it.

• Confirm your application is on a supported Laravel version. Laravel 9 is no longer supported by this release; plan to upgrade to Laravel 10 or 11 first.
• Require the new constraint, typically ^1.1, then run composer update and commit the resulting lockfile intentionally.
• Clear framework caches after upgrading: php artisan optimize:clear.
• If the package publishes config, migrations, or assets, re-check those published files against the new release before running migrations.
• First practical use case: install 1.1.0 in a Laravel 11 application, boot the package, run your existing test suite, and verify the package's main workflow end-to-end before rolling it out.

Implementation Patterns

• Treat 1.1.0 as a compatibility upgrade, not a feature upgrade. Keep the package version bump separate from unrelated application changes so regressions are easy to isolate.
• In Laravel 11 applications, rely on normal package discovery and container resolution unless the package documents manual provider registration.
• Wrap package calls behind a small application service or action class. This keeps future Laravel-version compatibility changes from spreading through controllers, jobs, and commands.
• For upgrades from Laravel 9, upgrade Laravel and the package in the same branch, then run the application test suite on the target Laravel version before merging.
• If the package exposes config, keep application-specific overrides in config/ or .env rather than editing vendor files.
• Add CI coverage for every Laravel version you actually support. At minimum, test Laravel 11 if that is your target; keep Laravel 10 coverage if your application still supports it.

Gotchas and Tips

• Dropping Laravel 9 is a breaking change for older applications. Composer will block installation if your root laravel/framework constraint still allows or requires Laravel 9.
• Do not reuse an old composer.lock blindly. Resolve dependencies deliberately and verify that transitive packages also support Laravel 11.
• Check for stale caches after upgrading: config cache, route cache, and package discovery cache can mask provider or config changes.
• Use composer why-not vendor/package 1.1.0 to diagnose constraint conflicts, and php artisan about to confirm the running Laravel version.
• The release notes do not advertise new extension points. Continue using documented config publishing, service-provider bindings, and package events/contracts rather than relying on internal classes.
• If the package has no Laravel 11-specific test coverage in your app, add a smoke test that boots the package, resolves its main service, and exercises its primary workflow.