Laravel Model Json Laravel Package

Product Decisions This Supports

• Framework upgrade planning: v1.5.0 is a Laravel 5.8 compatibility release driven by a change to how model function scopes behave. This directly informs our Laravel upgrade roadmap — the package is a dependency that gates our ability to move to 5.8, and the maintainer has published a clear support matrix rather than leaving us to discover breakage in staging.
• Dependency version pinning policy: The release explicitly splits support (~1.4.* for Laravel ≤5.7, ^1.5 for Laravel ≥5.8). This is a decision input for how we constrain composer.json per application and whether we standardize on a single Laravel minor across the fleet or allow mixed versions.
• Build vs. buy: Because the breaking change originates in the framework, not the package, this confirms the maintainer is actively tracking Laravel internals. That responsiveness is an argument for keeping the dependency (buy) rather than absorbing scope-handling logic into our own codebase.
• Release sequencing: Any product work shipping on Laravel 5.8 must land on ^1.5; work on 5.6/5.7 stays on ~1.4.*. This affects sprint planning for upgrade tickets and the order in which we upgrade services.
• Use cases: Any feature relying on model query scopes — filtering, search, reporting endpoints, admin list views — inherits this compatibility requirement. Feature owners should be told their scope-based code must be validated against the pinned version.

When to Consider This Package

Adopt or retain when:

• We are on Laravel 5.8 (use ^1.5) or on 5.6/5.7 with no near-term upgrade (pin ~1.4.*).
• Our application leans on model query scopes and we want that behavior maintained by a third party that tracks framework internals.
• We value an explicit, published compatibility matrix over silent breakage — the release notes state the support boundary plainly.

Look elsewhere or defer when:

• We are on Laravel 5.5 or earlier and cannot upgrade — confirm the maintainer still supports that line, since these notes only address 5.7/5.8 boundaries.
• The package's scope behavior overlaps with first-party Laravel features or another dependency we already carry; duplication adds upgrade surface for no benefit.
• We require a long-term support guarantee (LTS commitment, security response SLA) that a single-maintainer package cannot offer.
• We are mid-freeze on a release train: the 1.4→1.5 jump should not be taken opportunistically alongside a Laravel upgrade without a dedicated test pass on scope behavior.

Note that this release is a compatibility bump, not a feature release — there is no new capability to evaluate on its own merits.

How to Pitch It (Stakeholders)

For executives: We depend on a small PHP package that handles query scopes in our Laravel applications. The maintainer has shipped a release aligned to Laravel 5.8. Nothing breaks on our current version, but our framework upgrade is now a two-part task: upgrade Laravel, and move this package from the 1.4 line to the 1.5 line in lockstep. The cost is a scheduled upgrade ticket and a regression pass on scope-driven screens, not a re-architecture.

For engineering: Version 1.5.0 responds to Laravel 5.8's change in function scope behavior. Pin ~1.4.* while on Laravel ≤5.7 and ^1.5 on ≥5.8. The 1.4 and 1.5 lines diverge, so do not assume a single constraint works across the fleet. Upgrade order matters: bump Laravel and this package in the same change set, then regression-test filtering, search, and reporting paths that rely on scopes. If any service is on 5.5 or earlier, verify support separately — the notes only define the 5.7/5.8 boundary.