Nova Grouped Boolean Field Group Laravel Package

Product Decisions This Supports

• Admin panel roadmap and Nova upgrade timing. The 2.0.0 release adds Laravel Nova v4 support, which is the gating fact for any team planning a Nova v3 → v4 migration. This package is now viable on either major version, so its presence no longer blocks the platform upgrade — or, conversely, it is only a candidate for adoption once the Nova v4 baseline is confirmed.
• Build vs. buy for internal admin tooling. Nova extensions exist to avoid bespoke admin CRUD work. With v4 support in place, this becomes a defensible "buy/integrate" line item: assess the feature gap it closes against the engineering effort of replicating it inside your own Nova resources.
• Feature scoping and release planning. Treat 2.0.0 as a version boundary, not a drop-in. A major bump aligned to a Nova major version typically signals that the previous line stays on v3. Budget the upgrade as its own ticket with regression testing on admin screens.
• Dependency risk register. A package whose latest release is explicitly tied to a Nova major version is a maintenance-health signal worth tracking. Confirm the maintainer intends to follow Nova v5 when it lands before you commit it to a multi-year roadmap.
• Use cases to validate: which Nova screens it accelerates (cards, fields, tools, metrics), whether it replaces or supplements native Nova functionality, and whether it is exposed to end users or purely internal operators.

When to Consider This Package

Adopt when:

• You are running, or actively planning to move to, Laravel Nova v4 — this release is the compatibility gate.
• The package's specific admin capability (card/field/tool/metric) maps to a screen you would otherwise hand-build, and the build estimate exceeds the integration and maintenance cost.
• Your team already owns Nova licensing and the admin surface is a first-class product area rather than an afterthought.
• The maintainer shows a release cadence that tracks Nova majors — 2.0.0 is evidence of intent, not proof of a durable pattern.

Look elsewhere when:

• You are still on Nova v3 with no near-term upgrade. Pin to the pre-2.0 line only if it is still supported; otherwise the upgrade becomes a forced dependency.
• The package is a thin wrapper over something you can express in a few dozen lines of Nova PHP — the dependency cost outweighs the savings.
• Nova is not part of the stack (Livewire/Filament/Inertia-based admin instead) — v4 support here is Nova-specific and does not transfer.
• You need guarantees: check the license, support SLA, open-issue trajectory, and whether a 2.0 major implies breaking API changes for anyone already integrating.
• The admin surface is customer-facing and subject to strict accessibility, performance, or design-system requirements the package does not satisfy.

How to Pitch It (Stakeholders)

For executives: This is a small, targeted dependency for our Laravel admin panel. The new 2.0.0 release adds support for Nova v4, the current major version of the framework our admin tooling is built on. That matters for one decision: it keeps our admin upgrade path open and lets us evaluate the package as a substitute for custom internal tooling rather than a blocker. No spend or strategic commitment is implied until we confirm fit.

For engineering: Version 2.0.0 is a major release whose headline is Nova v4 compatibility. Treat it as a breaking boundary — do not assume a drop-in from 1.x. Before adoption, confirm (a) the exact Nova features it provides, (b) the 1.x → 2.x changelog for API breaks, (c) whether 1.x remains patched for any Nova v3 surfaces we still run, and (d) test coverage for Nova v4. Recommend a timeboxed spike against one real admin screen, with the upgrade ticket estimated separately from the integration ticket.