Valii Laravel Package

Product Decisions This Supports

• Platform upgrade planning (Laravel 12/13, PHP 8.4/8.5): Release 0.6.19 confirms the package tracks current and upcoming Laravel/PHP versions. This is the primary decision this release unblocks — whether fusic/valii can stay in the dependency tree when the application moves to PHP 8.4/8.5 or Laravel 12, and whether it is a credible bet for a Laravel 13 roadmap.
• Build vs. buy for the capability it provides: If your team is currently hand-rolling the functionality valii covers, this release is a signal the package is maintained rather than abandoned, which weakens the case for a custom internal implementation.
• Adoption risk tier: The package remains on 0.6.x — pre-1.0. Treat it as a "convenience dependency," not a load-bearing platform component: acceptable where it saves engineering time, not acceptable where an undocumented API change would block a release.
• Dependency freeze exceptions: If your policy pins only dependencies with demonstrated support for your target PHP/Laravel matrix, 0.6.19 is the version to reference when requesting an exception or a version bump.
• Vendor concentration risk: A first-time contributor plus a maintainer-driven release cadence means no meaningful change to the bus-factor assessment. Do not treat this release as evidence of a growing contributor base.

When to Consider This Package

Adopt when:

• You are on, or actively planning, Laravel 12 and PHP 8.4/8.5 — this release is the compatibility gate, and older pins (≤0.6.18) will increasingly become the blocker in upgrade work.
• The functionality it provides is a genuine time-saver over in-house code and is used in a bounded, non-critical path (form handling, admin tooling, internal apps).
• You can pin an exact version in composer.json and can absorb a minor-version API change inside a normal sprint.
• You want a Japanese-maintained package with upstream alignment to the latest framework releases — relevant if your team already relies on Fusic tooling.

Look elsewhere when:

• You need a stable public API contract (1.0+) before adopting — 0.6.x signals the maintainers still reserve the right to change things.
• The dependency would sit on a critical path (payments, auth, data integrity) where a lagging compatibility release could block a security patch.
• Your stack is on an older Laravel/PHP combination and you need long-term support guarantees rather than forward-looking compatibility.
• You require multi-maintainer governance, published security policy, or SLA-backed support.
• The capability is small enough to implement and own in-house with less total risk than an external pre-1.0 dependency.

How to Pitch It (Stakeholders)

For executives: A small, actively maintained open-source Laravel component (fusic/valii) shipped a maintenance release adding support for the current and next Laravel and PHP versions. No new features, no breaking changes, no action required on existing usage. The takeaway is continuity: the dependency is not abandoned and will not block our platform upgrade. It is not a strategic bet — it's a pre-1.0 utility library, so we hold it at a pinned version and keep an exit path.

For engineering: 0.6.19 is a compatibility-only release — the changelog is a single PR adding Laravel 12/13 and PHP 8.4/8.5 to the supported matrix. Practical consequences: (1) this is the version to pin when we move to PHP 8.4/8.5 or Laravel 12, so it should be folded into that upgrade ticket rather than shipped standalone; (2) verify our actual usage against the package's tests on the new matrix before relying on "supported" as "verified for us"; (3) note a first-time contributor joined — positive, but bus factor is unchanged; (4) still 0.6.x, so keep it pinned exactly and treat any 0.x minor bump as potentially breaking on review.