Eloquent Ci Relations Laravel Package

Product Decisions This Supports

• Framework upgrade planning / platform roadmap — v1.6.0 adds support for illuminate/database v13, meaning the package tracks Laravel's next major. This de-risks the "Laravel 13 upgrade" line item: you can sequence the app upgrade without waiting on a third-party blocker or forking the package.
• Build vs. buy — a package sitting on the database layer is a "buy" decision for anything non-differentiating (query helpers, model behaviors, schema tooling). A steady compatibility-release cadence is the core evidence for continuing to buy rather than absorbing maintenance in-house.
• Dependency risk / support matrix — this release gives you a defensible support window: if you're on Laravel 12 and planning 13, the package is not the long pole. It may also set a floor — confirm whether older Laravel versions were dropped before committing to a mixed-version fleet.
• Use cases — any feature work that reads/writes through Eloquent or the query builder (reporting, data sync, admin tooling, tenant-scoped queries) inherits this dependency. A compatibility release is a green light to keep building on it; it is not a change in capability.

When to Consider This Package

• Adopt when your product is on Laravel (or will be) and the package's abstraction removes code you'd otherwise write and maintain — especially where it is tightly coupled to illuminate/database behavior you'd have to reimplement.
• Adopt when upgrade cadence matters: this release is evidence the maintainer ships compatibility updates for new Laravel majors rather than lagging behind.
• Look elsewhere / re-evaluate when:
  • You are not on Laravel, or you pin to an older major and this turns out to be a floor bump rather than an additive constraint — the notes don't say, so check composer.json before assuming it's backward-compatible.
  • The package duplicates first-party Laravel/Eloquent capability you already have.
  • You need guarantees this note doesn't provide: no mention of bug fixes, security patches, or behavioral changes. Compatibility-only releases say nothing about quality.
  • Bus factor / maintenance is a concern: a one-line release note is weak evidence on its own. Check commit history, issue responsiveness, and whether CI actually runs against v13 (pre-release Laravel support is often aspirational until GA).

How to Pitch It (Stakeholders)

To executives: This is a routine but useful maintenance release — the package now supports the next major version of Laravel's database layer. In plain terms, one of our dependencies won't block our next platform upgrade. No new spend, no migration project, no user-facing change; it protects a roadmap item and reduces the risk of an unplanned "stuck on an old framework" scenario later.

To engineering: v1.6.0 widens the illuminate/database constraint to include v13. Treat it as a compatibility bump, not a feature release — no behavioral changes are claimed. Before upgrading: confirm whether the constraint is additive or a floor bump (does it still support our current Laravel version?), verify v13 support is actually tested in CI, and check whether v13 is GA or pre-release on our target timeline. If we're still on an older Laravel, pin accordingly; if we're planning the v13 upgrade, this package is now off the critical path. Recommend bumping in a low-risk window and letting it ride through normal regression testing rather than scheduling dedicated QA.