Product Decisions This Supports
- Platform-baseline decision (the headline). v1.1.0 raises the minimum PHP version to 8.1. That is a minor version bump carrying an environment-breaking change for anyone on PHP 8.0 or below. Treat this as a portfolio-level question: "Are all services consuming this package already on 8.1+, and if not, what is the migration cost?" Answer that before approving the upgrade anywhere.
- Build vs. buy on enum plumbing. Native enum support means less bespoke code in our own repos — no hand-rolled casts, accessor methods, or whitelist arrays to keep an enum column in sync. The buy case strengthens: fewer lines of code we own and maintain.
- Domain-modeling roadmap. If the product is moving toward typed statuses, roles, order states, or other finite-value fields, this release unlocks using PHP native enums end-to-end rather than string constants. That is a concrete argument for prioritizing "typed domain vocabulary" work in the next cycle.
- Upgrade sequencing / dependency policy. Decide explicitly: pin to
^1.0 on legacy services that cannot move yet, while greenfield and already-modernized services go to ^1.1. This is a routine decision, not a fork in the road — but it needs to be written down so it isn't re-litigated per team.
- Versioning caveat to log. A PHP-floor increase shipped as a minor version is a semver smell. Note it for our internal dependency-review checklist: read changelogs before
composer update, don't rely on version numbers alone.
Caveat: this assessment is derived solely from the v1.1.0 release note. No prior assessment or package-level data was available, so scope claims (what the package actually does beyond enum handling) are inferred and should be confirmed against the README before adoption.
When to Consider This Package
Adopt when:
- The fleet is already on PHP 8.1+ (and ideally 8.2+, given 8.1 is late in its security-support window), so the floor change costs nothing.
- The product genuinely leans on enum-like fields and the package's enum handling removes real custom code rather than replacing three lines with a dependency.
- We're standardizing on a supported Laravel version whose own PHP floor is already 8.1+ — the constraint then disappears entirely.
Look elsewhere or hold when:
- Any consuming service is pinned to PHP 8.0 or 7.4. Stay on the 1.0.x line and revisit; do not let a transitive dependency dictate a platform upgrade.
- The need is narrow enough that Laravel's built-in enum casting, validation, and rules cover it. Adding a dependency for capability the framework already ships is a net negative on maintenance.
- The package's core value proposition is something other than enum handling — in that case this release is incidental and shouldn't be the reason to adopt or reject it.
- We can't confirm the package's maintenance posture (release cadence, issue responsiveness, test coverage). One release note is not enough signal for a dependency we'd carry long-term.
How to Pitch It (Stakeholders)
For executives: A small, low-cost dependency upgrade that reduces the amount of custom code we write and maintain around status fields and other fixed-value data. The tradeoff is that it requires our PHP runtime to be at 8.1 or newer — which, for most of our services, is a version we should be on anyway. No product-facing behavior change; the decision is about engineering hygiene and where we spend maintenance effort.
For engineering: v1.1.0 adds first-class support for PHP 8.1 native enums. That means typed enum values can flow through the package without custom casts or accessors, which improves static analysis, IDE support, and refactor safety. The catch: the PHP floor moves to 8.1, shipped as a minor version. Recommended handling: pin ^1.0 for any service not yet on 8.1, upgrade the rest to ^1.1, and add "verify PHP floor in changelog" to the dependency-review routine. Before rollout, confirm the package's broader capability set and maintenance health — we're working from a single release note here, not a full evaluation.