Eloquent Enum Cast Laravel Package

Product Decisions This Supports

• Build vs. buy / dependency adoption: Whether to take on an external Laravel/PHP package versus building and maintaining equivalent logic in-house. Release 1.4.0 restores PHP ^8.0 support, which removes a platform-upgrade prerequisite from that decision.
• Roadmap sequencing: Teams with applications still on PHP 8.0 (common in Laravel 8/9 estates and client-managed environments) can adopt on their current upgrade timeline instead of pulling a PHP 8.1+ migration forward. That decouples "adopt this capability" from "modernize the runtime."
• Budget and staffing: No forced platform migration means no ring-fenced engineering time, no regression testing across the host application, and no coordinated release window. The adoption cost is closer to integration-only.
• Delivery risk: A broader supported PHP range reduces the chance of the package being pinned out by a future framework or host upgrade, and reduces the odds of needing a fork to hold 8.0 compatibility.
• Due diligence signal: The "reverted back" wording implies the 8.0 floor was dropped in an earlier release and has now been reinstated. Confirm whether any published version became unusable for 8.0 consumers, and pin to 1.4.0 rather than a floating constraint.

When to Consider This Package

Adopt when:

• The host application runs PHP 8.0 or newer — 1.4.0's floor is 8.0, so 8.0 environments are explicitly back in scope.
• The capability it provides is on the roadmap but is not a core differentiator; buying the dependency is cheaper than owning the maintenance.
• Your fleet spans multiple PHP minor versions and you want one dependency that covers all of them without per-app pins.
• You are willing to track the package's support matrix release-by-release, since the PHP floor has already moved once in each direction.

Look elsewhere when:

• You need PHP < 8.0 (7.4 and below are out of scope).
• You need a vendor with a contractual LTS policy, security SLA, or published deprecation schedule — release-note-only compatibility changes are a weak governance signal for regulated or long-horizon products.
• The functionality is differentiating enough that a third-party support-matrix decision should not sit on your critical path.
• Your platform standard is a single pinned PHP version and you gain nothing from the widened range — in that case the churn is cost without benefit.

How to Pitch It (Stakeholders)

For executives: We are evaluating a Laravel/PHP dependency rather than building the capability ourselves. The new 1.4.0 release restores PHP 8.0 support, which means adoption no longer forces a runtime upgrade — no additional engineering budget, no migration project, no separate release train. Recommendation is to pilot on one application, pin to 1.4.0, and revisit if the package's supported PHP range shifts again.

For engineering: 1.4.0 reverts the PHP floor to ^8.0. Verify your deployment targets actually satisfy ^8.0, pin the exact version in composer.json rather than using a caret constraint on the package, and add a CI job that runs against your oldest supported PHP minor. Treat the support-matrix change as a tracked risk item: it has now moved in both directions, so budget a small amount of ongoing diligence per upgrade, and confirm the changelog for any interim release that may have broken 8.0 consumers before you standardize on it.

Confidence note: This assessment is based on release metadata only — no feature-level or adoption evidence was available. Validate the functional fit and maintenance activity (release cadence, issue responsiveness, test coverage) before committing beyond a pilot.