Last Modified Laravel Package

Getting Started

This release (4.4.0) is a compatibility drop: the only functional change is Laravel 13 support. Everything else is housekeeping (LICENSE year, README banner/preview images). Treat it as a low-risk minor upgrade, not a feature release.

Minimal steps to adopt it:

1. Confirm your own constraints first. Check composer.json for the package's illuminate/* / laravel/framework requirement range. If it reads something like ^10.0|^11.0|^12.0|^13.0 after this release, you can install on a Laravel 13 app; if it still caps at ^12.0, 4.4.0 is not usable there yet regardless of the release note wording.
2. Verify the PHP floor. Laravel 13 raises the minimum PHP version (Laravel 12 required PHP 8.2+). Cross-check the package's require.php against your runtime before bumping — a package can claim L13 support while still declaring a lower PHP floor than your app allows, or vice versa.
3. Upgrade in a scratch branch: composer update vendor/package --with-dependencies, then run your test suite and composer why-not if resolution stalls.
4. Look first at: the README (installation + usage), CHANGELOG.md for the full history rather than just this release body, and composer.json (require, extra.laravel.providers, extra.laravel.aliases) to see whether service providers and facades are auto-discovered.

First use case: install on a Laravel 13 app, confirm the provider is discovered (php artisan about or php artisan package:discover output), and exercise the package's main documented entry point once. If the package ships config, views, migrations or translations, publish them now and commit the published files so later upgrades are diffable:

php artisan vendor:publish --provider="Vendor\\Package\\PackageServiceProvider"

Implementation Patterns

Pin the major, float the minor. Because 4.4.0 is additive within the 4.x line, "vendor/package": "^4.4" is the right constraint — you get the Laravel 13 support without accepting an unvetted 5.x.

Keep a Laravel-version matrix in CI. The reason this release exists is upstream drift. Add a job matrix that runs the package against the Laravel versions you actually deploy, so the next Laravel major is a scheduled task rather than an incident:

matrix:
  laravel: ['12.*', '13.*']
  php: ['8.3', '8.4']

Test against the framework, not around it. If you write integration coverage for this package's behaviour, use orchestra/testbench and tie its version to the Laravel version under test — a stale Testbench is the most common cause of "L13 support doesn't work for me."

Automate the dependency bump. Since the package follows Laravel majors promptly (a solo-maintainer pattern), let Renovate/Dependabot open the PR and let CI decide. Human review then focuses on the changelog rather than the constraint arithmetic.

Integration tip for multi-version apps. If you maintain one codebase deployed to two Laravel versions, keep the package constraint wide (^4.3|^4.4) and gate any 4.4-only behaviour behind a version_compare or a resolved-container check rather than branching on framework version directly.

Lockstep upgrade ordering. When moving an app to Laravel 13, upgrade the framework and its first-party packages first, then third-party packages like this one, then your own code. Doing it the other way round produces constraint errors that point at the wrong package.

Gotchas and Tips

• Read the diff, not the release body. This changelog is dominated by bot commits (LICENSE year, banner image, README preview). The single substantive line is the Laravel 13 entry. Always confirm against the compare view — a "minor" tag with three image commits still deserves a one-minute git diff on src/ and composer.json.
• Compatibility-only releases can hide constraint widening. "Laravel 13 compatibility" sometimes means the maintainer also dropped support for older Laravel or PHP versions in the same PR. Check whether the lower bounds moved; if they did, this is effectively breaking for anyone on Laravel 10/11.
• composer update vs require. Adding ^4.4 to composer.json without updating the lock file leaves production on 4.3.x. Verify with composer show vendor/package in the deployed environment, not locally.
• Provider/facade cache. After upgrading, run php artisan package:discover (or optimize:clear) — stale bootstrap/cache/packages.php is the usual reason a newly supported framework version reports a missing provider.
• Debugging resolution failures. composer why-not vendor/package 4.4.0 names the exact package blocking the upgrade far faster than reading conflict output. Common culprits are a pinned orchestra/testbench or another package still capped at ^12.0.
• Low maintenance velocity is the real signal. A release consisting mostly of automated image commits suggests the package is in steady-state maintenance. That's fine for a utility package, but budget for the possibility that a future Laravel major lands before the maintainer gets to it — keep a fork or an alternative in mind for anything load-bearing.
• Extension points. Before relying on custom behaviour, check whether the package exposes config-driven overrides or bindable contracts in its service provider. If it does, your customisations survive version bumps; if you're subclassing internals, expect image-and-LICENSE releases to occasionally reorder things you depended on.
• Don't skip the app's own tests. "No breaking changes" is the maintainer's claim about their public API, not about your usage of it. Run your suite on the new version before merging.