Nova Policy Laravel Package

Product Decisions This Supports

• Admin/back-office roadmap and upgrade timing. This is a major version (v2.0.0) whose only stated change is "Upgrade to nova 4." That means the package's forward path is now tied to Laravel Nova 4. If your internal tooling roadmap includes a Nova 4 migration, this release is the green light for this dependency; if you are staying on Nova 3, this release is effectively out of scope for you and your roadmap should not assume new features on that line.
• Platform upgrade sequencing. A dependency that only supports Nova 4 on its 2.x line creates a coupling: the Nova upgrade, the Laravel/PHP version bump that Nova 4 requires, and this package's upgrade must land together. Treat them as one work item, not three, when sequencing the quarter.
• Build vs. buy for admin surface area. Every capability this package provides inside Nova is functionality your team does not hand-build. The v2.0.0 release is a signal that the vendor/maintainer is still investing in the package and following the platform, which is the main thing that keeps "buy" cheaper than "build" over a 2–3 year horizon.
• Use cases this unlocks or preserves. Anything your ops, support, or internal-tooling users do through the Nova admin panel that depends on this package. If that workflow is on the critical path for a launch or a seasonal peak, the Nova 4 upgrade becomes a delivery risk to schedule deliberately rather than opportunistically.
• Dependency and version-pinning policy. A major-version bump with a one-line changelog is a concrete test case for your pinning and upgrade-review policy. Decide now whether ^2.0 is allowed in composer.json or whether the constraint is pinned until regression testing completes.

When to Consider This Package

Adopt it when:

• You are on, or committed to migrating to, Nova 4. This release exists to serve that case and nothing else is claimed.
• Your product depends on the specific admin-panel capability the package provides, and re-implementing it natively in Nova is more expensive than taking the dependency.
• The maintainer's release cadence tracks the platform (this release suggests it does) and the package has a credible history of shipping compatible versions reasonably soon after Nova majors.
• You can absorb a major version — i.e., you have the test coverage or the manual QA capacity to validate the admin panel after upgrading, and you are not mid-freeze.

Look elsewhere or defer when:

• You are staying on Nova 3. Check whether the 1.x line is still maintained; a major bump often signals the start of a support tail on the prior line rather than an immediate cutoff, but you need that answer in writing before you depend on it.
• You do not use Nova at all, or Nova's built-in features already cover the need — a third-party package is permanent surface area you have to upgrade forever.
• You need more than the changelog tells you before committing. "Upgrade to nova 4" says nothing about breaking API changes within the package itself, config or migration changes, or a documented upgrade path. Action: request the upgrade guide or read the diff before scheduling the work. Absence of that documentation is itself an adoption risk signal for a major version.
• The package is a single-maintainer project with no recent activity beyond this release and no issue-tracker responsiveness — verify before you build a workflow on top of it.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost dependency that powers part of our internal admin tooling. A new major version has shipped that keeps it compatible with Laravel Nova 4, the current major release of our admin framework. The decision it forces is timing, not budget: we should either migrate our admin panel to Nova 4 in a planned window, or consciously defer and stay on the prior supported line. There is no user-facing feature here — the value is staying on a supported platform so we are not accumulating upgrade debt or running unsupported software. Recommendation: schedule the Nova 4 migration as a scoped, time-boxed work item with regression testing, and do not upgrade the package outside that window.

To engineering: v2.0.0 is a major version whose stated change is Nova 4 support. Treat it as breaking until proven otherwise — pin the current version, read the diff or upgrade guide, and confirm (a) whether 1.x remains maintained for Nova 3, (b) any config, migration, or public API changes inside the package, and (c) the Laravel/PHP floor implied by Nova 4. Sequence the Nova 4 upgrade, the framework version bump, and this package's 2.x bump as a single PR set behind the same test pass. Add or extend smoke coverage on the admin screens this package touches before you merge, since that is the only regression net you will get from a one-line changelog. Report back the upgrade guide status and the 1.x maintenance answer so we can finalize the roadmap commitment.