Eloquent Utils Laravel Package

Product Decisions This Supports

• Stack upgrade sequencing. The single most concrete decision this release informs is when your team moves to PHP 8.4 / Laravel 12. As of 0.4.0 the package supports exactly one PHP minor (8.4) and one Laravel major (12) — support for PHP 8.3 and Laravel 11 was removed, not deprecated. Adopting this package means committing to upgrade your application in lockstep with it.
• Build vs. buy for narrow, version-sensitive functionality. A package whose support matrix moves in single-version steps is best treated as a thin, replaceable dependency. If the functionality it covers is core to your product, budget for the real (if small) possibility of vendoring or reimplementing it rather than inheriting its upgrade cadence.
• Roadmap risk flagging. Being at 0.4.0 with a support-matrix break in a minor release tells you the API surface is still settling. Any roadmap item that depends on this package should carry an explicit "revisit at 1.0" checkpoint rather than being locked in for a multi-quarter horizon.
• Release-train alignment. If your platform upgrade (PHP 8.4 / Laravel 12) is already scheduled, this package is now adoptable on that target. If your upgrade is not scheduled, this release effectively un-adopts you — a useful forcing function to sequence the two together.
• Compliance and lifecycle posture. Dropping a PHP minor and a Laravel major without a deprecation window signals a maintainer who prioritizes a small, current support surface over backward compatibility. That is a legitimate posture (less code to maintain, security-current by default), but it constrains how much EOL-lag your org can tolerate.

When to Consider This Package

Consider it when:

• You are already on, or actively migrating to, PHP 8.4 and Laravel 12 — the package aligns with the front of the ecosystem rather than the trailing edge.
• The functionality it provides is well-bounded and not deeply entangled with your domain logic, so swapping it out later is a bounded task rather than a refactor.
• Your organisation runs a fast upgrade cadence (upgrading Laravel majors within weeks of release, not quarters), which makes a single-version support window a non-issue.
• You need an actively maintained, security-current dependency and would rather take aggressive version pruning than carry a package that lags on PHP support.
• You are prototyping or building new on the latest stack, where there is no legacy compatibility surface to protect.

Look elsewhere when:

• You are on PHP 8.3 or Laravel 11 and cannot move on the package's timeline. There is no supported configuration for you — this is a hard blocker, not a warning.
• You need a multi-version support window (common in agencies, multi-tenant platforms, or products shipping to customers who control their own runtime).
• You need API stability guarantees — at 0.x with a support break in a minor release, downstream breaking changes are a reasonable expectation. If you need to promise stability to your own customers, wait for 1.0.
• You require a formal deprecation policy or an LTS-style commitment as an internal procurement or security-review condition.
• The package would sit in a long-lived, low-touch service where dependency churn is disproportionately expensive relative to the value delivered.

How to Pitch It (Stakeholders)

To executives: This package is now current with the latest PHP (8.4) and Laravel (12), which is good for security posture — it will not be the dependency holding us back on patches. The trade-off: it supports only those latest versions, so it commits us to staying current rather than letting our platform age. It is also pre-1.0, which means the maintainer has not yet promised interface stability. Recommendation: viable on a modernisation track, not on a "keep the lights on" track — and worth a formal checkpoint at 1.0.

To engineering: Version 0.4.0 adds PHP 8.4 and Laravel 12 support and removes PHP 8.3 and Laravel 11 — this is a breaking change in a minor release, permissible under 0.x semver but a clear signal about the maintainer's compatibility philosophy. Practical implications: adoption requires our app to be on Laravel 12 / PHP 8.4 (or the upgrade scheduled in the same window); pin the version explicitly and read the changelog on every bump rather than relying on caret ranges; keep our usage behind a thin internal interface so replacement or vendoring stays cheap. Verify the removed-version claim in CI — a matrix that tests only the newest versions means regressions against older runtimes go undetected by upstream, which is fine if we never run those runtimes and a trap if we do.