Laravel Model Repositories Laravel Package

Product Decisions This Supports

• Framework upgrade sequencing. This package's major version tracks Laravel's major version 1:1. v7.0.0 adds Laravel 13 support and removes Laravel 11 support, which means "upgrade Laravel" and "upgrade this package" are a single workstream, not two. That's a roadmap input: budget one combined effort per Laravel release cycle rather than discovering a forced dependency bump mid-sprint.
• Minimum supported platform. Adopting v7 sets a hard floor at Laravel 12. If any service, tenant, or customer-hosted deployment still runs Laravel 11, v7 is not adoptable there — those properties stay pinned to v6 and fall off the upstream fix path.
• Build vs. buy / dependency ownership. Taking this package means inheriting an external upgrade cadence that is explicitly not long-term-support-friendly. The tradeoff is favorable (predictable, well-signposted breaking changes) but it is a real recurring cost that belongs in the estimation, not the fine print.
• Vendor health signal. Shipping Laravel 13 support in the same release that drops Laravel 11 is a positive maintenance signal — the maintainer is keeping pace rather than accumulating compatibility debt. It also means the project is willing to make clean breaks, so expect a v8 at the next Laravel major.
• Support-matrix and deprecation policy. The L11 removal gives a concrete precedent to point at when writing your own internal dependency policy: majors are supported for roughly two Laravel cycles, then dropped.

When to Consider This Package

Consider it when:

• You are on Laravel 12 or 13 today, or will be within the current planning horizon.
• You are willing to upgrade this package in lockstep with each Laravel major, and you have a process that makes that routine.
• You value explicit, versioned breaking changes over a dependency that quietly carries years of legacy compatibility.

Look elsewhere, or deliberately hold at v6, when:

• You are on Laravel 11 or earlier with no near-term upgrade path — v7 is a wall, and v6 will not receive upstream fixes indefinitely.
• You ship a long-term-support product whose support window exceeds Laravel's own; this package's cadence will outrun yours.
• You need a vendor commitment to a fixed LTS horizon. This release demonstrates the opposite posture.

Caveat on this assessment: the release data covers compatibility and lifecycle only. It says nothing about the package's functional surface, so product fit still needs a separate evaluation — treat the above as the adoption-risk view, not the capability view.

How to Pitch It (Stakeholders)

To executives: This is a routine dependency decision with a predictable cost shape. The package stays current with Laravel — v7 supports Laravel 13 — which is what we want from a dependency. The price is a scheduled major upgrade each time Laravel ships one, and it does not carry open-ended legacy support. That is a trade we should make deliberately and budget for, not one we should discover late.

To engineering: v7.0.0 is a breaking release. It adds Laravel 13 and drops Laravel 11. Plan it as part of the Laravel 13 upgrade, not after it. Any service still on Laravel 11 stays on v6 and should be understood as unsupported upstream — that's an accepted risk to record, not an oversight. Our ask before committing: confirm the Laravel version across all services, then schedule the bump alongside the framework upgrade.