Laravel Follow Laravel Package

Getting Started

Version 6.0.0 is a platform-compatibility major, not a feature release. The only substantive changes are the floor raises: Laravel 13+ only and PHP 8.3 minimum, plus refreshed testbench/phpunit/tooling and a new AGENTS.md.

Start here before anything else:

1. Confirm you can even install it. Run php -v and check laravel/framework in composer.json. If you are on Laravel 12 or PHP 8.2, stay on the 5.x line — 6.0.0 will not resolve.
2. Read AGENTS.md first. It is the newest addition and the only new developer-facing documentation in this release. If you use an AI coding assistant or an agent-driven workflow, point it at this file before prompting; it encodes the conventions the maintainers expect for this major.
3. Diff composer.json and the CI config in the package repo rather than the source. For a release like this, the tooling diff tells you more about intended behaviour than the changelog does.
4. First use case: a throwaway Laravel 13 app with PHP 8.3, install the package, and exercise your existing usage once. There is no new API surface advertised, so the goal of that first run is to prove nothing changed in behaviour.

If you are already on Laravel 13 / PHP 8.3, the upgrade is effectively a composer update plus a test run. If you are not, this release is a hard stop, and the real work is the framework upgrade, not the package upgrade.

Implementation Patterns

Treat 6.0.0 as a lockstep dependency, not an independent one. Pin the package alongside the framework in the same PR that moves you to Laravel 13. Splitting "upgrade Laravel" and "upgrade this package" into separate deployments doubles your bisect surface for no benefit, because 6.x cannot run without 13.

Constrain broadly, resolve narrowly. In composer.json, allow ^6.0 for the package while your application requires laravel/framework:^13.0. Resist ^5.0 || ^6.0 unions during the transition — they let CI silently resolve back to 5.x on a machine with an older PHP, which masks the real failure until production.

Keep a compatibility branch warm. If you maintain downstream packages or internal modules that depend on this one, branch 5.x-compat off your current code before bumping. That gives you a place to backport security fixes while the Laravel 13 migration lands.

Make the tooling refresh work for you. The testbench/phpunit updates in this release mean the package's own test suite is the reference implementation for the new major. When you hit an ambiguous behaviour, read the package's tests at the 6.0.0 tag — they were rewritten for this platform and are more current than any prose docs.

Wire AGENTS.md into your agent workflow deliberately. Copy its conventions into your repo's own agent instructions (or reference it), so generated code follows the same patterns the maintainers use. Treat it as the canonical style guide for this major, and re-read it after each minor release — it will likely change faster than the changelog.

Run a two-cell CI matrix during migration: PHP 8.3 + Laravel 13 (the new supported path), and your current stack on the previous major. Delete the old cell once the upgrade ships.

Gotchas and Tips

• composer update will not tell you why it failed. A Laravel 12 or PHP 8.2 environment produces a resolution error that often names a transitive dependency rather than the real cause. Check composer why-not <vendor>/<package> 6.0.0 before debugging anything else.
• PHP 8.3 is a real floor, not a soft one. If your local machine or a CI image is on 8.2, you will get confusing syntax or platform-check failures rather than a clean "unsupported PHP" message. Verify the PHP binary in CI explicitly — container images lag.
• The version jump is breaking by declaration. Even with no documented API changes, a major bump plus a new testbench/phpunit generation is your signal to re-run the full suite, not just the tests that touch this package. Static analysis and test-helper APIs are the usual silent casualties of a testbench major.
• Do not infer feature changes from the version number. Nothing in these notes adds functionality. If a changelog elsewhere claims a new capability in 6.0.0, verify it against the tag — the release notes list compatibility and docs only.
• AGENTS.md is documentation, not configuration. It changes nothing at runtime. Do not expect it to alter behaviour, and do not add it to your deploy artefact if you strip non-runtime files.
• Extension points are unchanged, so existing customisations should carry over — but any code extending package internals is exactly what a testbench/tooling major tends to break. Re-run those tests first; they are your highest-risk surface.
• Debugging tip: when something behaves differently post-upgrade, diff against the previous major at the same call site rather than reading the 6.0.0 diff. For a compatibility release, unchanged source plus changed behaviour almost always means a dependency resolved differently, not a package regression.

Assessment caveat: the release notes for 6.0.0 describe platform requirements and tooling only, with no feature, deprecation, or API detail. This assessment reflects that scope. Once the package publishes fuller 6.x documentation, revisit the Implementation Patterns section — particularly anything describing extension points and configuration, which are asserted here as unchanged only because nothing indicates otherwise.