Laravel Model Repositories Laravel Package

Getting Started

This release is a compatibility-only major: v7.0.0 adds Laravel 13 support and removes Laravel 11. There are no new APIs to learn, so "getting started" is really about getting onto a supported version pair before you write any code against the package.

1. Check your Laravel version first. Run php artisan --version. If you're on Laravel 11, you cannot install v7 — you must either upgrade the framework to 12/13 or stay on the v6 line.
2. Read the constraint, not the changelog. Open the package's composer.json and look at require for illuminate/* and php. The removed Laravel 11 support and any PHP floor bump are the two things that will actually block you.
3. Install deliberately:

   composer require vendor/package:^7.0 --with-all-dependencies
   

   The --with-all-dependencies flag matters here because a major version bump usually drags framework constraints along with it.
4. First use case: treat v7 as a migration task, not a feature adoption. The concrete first step is a green composer update plus your existing test suite passing unchanged — if the package only bumped framework constraints, your tests should be the proof that nothing else moved.

If you are starting a fresh Laravel 13 project, v7.0.0 is the version you want; there is no configuration or bootstrapping change implied by the release notes.

Implementation Patterns

Pin the package to the framework, not the other way round. In composer.json, keep the package constraint explicit and let the framework version drive resolution:

"require": {
    "php": "^8.3",
    "laravel/framework": "^12.0|^13.0",
    "vendor/package": "^7.0"
}

CI matrix. The useful matrix for this release is framework × package, not just PHP × package:

matrix:
  laravel: ['12.*', '13.*']
  package: ['^6.0', '^7.0']
  exclude:
    - laravel: '13.*'
      package: '^6.0'   # v6 predates Laravel 13 support
    - laravel: '12.*'
      package: '^7.0'   # only if you want to hold 12 on v6 — see Gotchas

Upgrade workflow for an existing app:

1. Branch, bump the package to ^7.0 alone, run the suite. This isolates package breakage from framework breakage.
2. Then bump Laravel 11 → 12 in a separate commit, and 12 → 13 in a third. Squashing these makes bisecting a failure miserable.
3. Only after both are green, remove any illuminate/* or laravel/framework constraint shims you added to force resolution.

Long-lived branches. If you maintain a package that depends on this one, widen your own constraint rather than hard-pinning:

"vendor/package": "^6.0|^7.0"

and let Composer pick based on the host app's framework version. Hard-pinning ^7.0 in a library silently drops Laravel 11 consumers.

Deployment tip. Because this is a major, deploy it behind a feature-flagged release or a canary rather than a Friday-night hotfix — even compatibility-only majors can surface transitive dependency drift (a bumped symfony/* or nesbot/carbon) that only shows up at runtime.

Gotchas and Tips

• The Laravel 11 removal is a hard break, not a deprecation. There is no shim and no fallback. composer update on a Laravel 11 app will fail resolution rather than warn. Plan the framework upgrade as a prerequisite, not a follow-up.
• composer why-not vendor/package 7.0.0 is the fastest way to see what's holding you back — usually a transitive dependency or a stale composer.lock. Run it before you start hand-editing constraints.
• Watch the PHP floor. A Laravel 13 bump almost certainly raises the minimum PHP version (likely 8.3+). Check your CI images, Dockerfiles, and any shared hosting target before merging — a green local run on 8.4 tells you nothing about a production container on 8.1.
• Don't mix v6 and v7 in a monorepo where services share a lockfile-adjacent dependency graph. Two services on different Laravel majors need separate lockfiles or separate deploy pipelines.
• Config and service providers are the usual silent breakage point. Even a "compatibility-only" major sometimes refreshes config stubs. Run php artisan config:clear and php artisan vendor:publish --tag=... --force review after upgrading; diff published config rather than blindly overwriting.
• Extension points unlikely to have moved. Since no API changes were announced, any custom bindings, macros, or subclassing you've built should carry over — but if you override an interface, re-verify it in v7's src/ rather than assuming.
• Debugging a resolution failure: temporarily require laravel/framework:^13.0 explicitly to force the conflict to the surface, read the full Composer error (it names the exact constraint chain), then remove the temporary line.
• Lockfile hygiene: commit composer.lock after the upgrade, and don't let composer update be part of your deploy step for this release — resolve once, review the diff, ship the lock.

Caveat: the release notes describe only framework support changes. Everything above is scoped to version compatibility. If the package's own API changes in a future patch, re-check that section against its documentation rather than relying on this assessment.