Product Decisions This Supports
- Framework floor / platform roadmap: v2.0.0 requires Laravel 8.0+ and Apiz v4. This is effectively a decision point on which Laravel versions your product still supports; it aligns the package with a modern baseline and lets you drop maintenance for Laravel 6/7-era code paths.
- Build vs buy for API tooling: the package is an API-layer dependency (Apiz-based). The major-version realignment is a signal to re-evaluate whether to keep consuming it or absorb the equivalent behavior in-house, especially if your API surface is small.
- Dependency consolidation: pinning to Apiz v4 lets you standardize on one API toolkit version across services rather than straddling v3/v4 — a portfolio-level decision, not just a repo-level one.
- Upgrade budgeting: a v1 → v2 bump with a raised framework floor and a new major dependency is a breaking change. This should be scheduled as deliberate migration work (composer constraints, CI matrix, regression on API contracts), not a routine patch.
- Versioning/major-release precedent: the project is willing to cut breaking majors to track upstream. That is good for longevity signals but means you should plan for recurring migration windows in your roadmap.
- Use cases: best suited to Laravel 8+ products that expose an HTTP/JSON API and want a maintained abstraction for that layer rather than hand-rolling it per service.
Evidence base: release notes only (v2.0.0). Feature-level capabilities should be confirmed against the package's docs before committing.
When to Consider This Package
Consider adopting (or upgrading to) it when:
- Your application is already on Laravel 8.0 or newer, or is scheduled to be — v2.0.0 will not install on older majors.
- You are already on Apiz v4, or are willing to adopt it; the release hard-couples the two, so a divergent Apiz version becomes a blocker.
- You want a maintained, upstream-tracking API layer rather than an in-house implementation with no release cadence behind it.
- You can absorb a planned breaking-change migration with test coverage for your API responses/contracts.
- Your team is small enough that buying/consuming this layer is cheaper than owning it.
Look elsewhere (or stay pinned) when:
- You are on Laravel 6/7 or PHP versions below Laravel 8's requirement and have no near-term upgrade path — v2.0.0 is not viable, and staying on v1 means accepting an unmaintained branch.
- You are on Apiz v3 and cannot move; the v4 requirement makes this a two-dependency migration, which changes the cost calculus.
- Your API needs are thin or highly bespoke — the abstraction cost outweighs the benefit.
- You need guaranteed long-term support or SLAs; a young major version with a recent breaking release indicates an evolving, not frozen, API.
- You cannot allocate migration time this cycle — deferring is a legitimate decision, but record it as technical debt with an owner.
How to Pitch It (Stakeholders)
To executives: This is a maintenance-aligned major release. It keeps our API layer compatible with the Laravel versions we're already standardizing on and with Apiz v4, which reduces the risk of running an unsupported dependency. The tradeoff is a one-time upgrade effort, not a recurring cost — it should be scoped as a small, schedulable migration with a clear before/after test signal. Net effect: lower long-term maintenance exposure.
To engineering: v2.0.0 raises the floor to Laravel 8.0+ and moves to Apiz v4. Treat it as breaking: expect composer constraint changes, possible API-contract adjustments from the Apiz major bump, and updates to the CI version matrix. Sequence it as: pin/verify Apiz v4 compatibility, upgrade the framework floor, run the full API regression suite, then cut over. Do not let this land as an incidental composer update.
Bottom line for the decision meeting: adopt/upgrade if we're on Laravel 8+ and Apiz v4 is acceptable; otherwise stay pinned with a documented review date. Either way, the decision is about the Laravel floor and the Apiz version, not about individual features.