Nova Targomaan Laravel Package

Product Decisions This Supports

• Platform upgrade sequencing (Laravel Nova 3 → Nova 4). This release is a compatibility cut, not a feature release. Its primary product value is unblocking the Nova 4 migration already sitting on the roadmap: it converts "we can't upgrade Nova because this package breaks" into a schedulable work item. The decision it supports is when to sequence the Nova 4 upgrade against other roadmap commitments, not whether the package is worth having.
• Support matrix and end-of-life policy. v2.0.0 declares Nova 4 as the supported target and implicitly makes v1.x the Nova 3 line. That is a decision point: how long do we keep shipping or pinning v1.x for customers on Nova 3, and do we maintain a dual-support window or force a hard cutover? PMs should treat this as the moment to publish an explicit support policy rather than let it be inferred from tags.
• Build vs. buy for admin/back-office tooling. If this package supplies Nova fields, cards, or resources we would otherwise hand-roll, the Nova 4 upgrade cost is the "buy" side of the ledger. Comparing a coordinated version bump against rebuilding equivalent admin UI in-house is the concrete trade-off this release makes legible.
• Customer-facing release communication and upgrade guidance. A major version bump on a Laravel package will surface in composer constraints for downstream teams. The product decision is whether this ships with an upgrade guide, a changelog entry, and a deprecation note for v1.x — and who owns that content.
• Risk acceptance on dependency coupling. Adopting a package whose release cadence is pegged to a proprietary, license-gated framework (Nova) means our upgrade clock is partly set by someone else's commercial release schedule. This release is a data point for that risk assessment.

When to Consider This Package

Adopt if:

• You are running Laravel Nova 4 (or are committed to migrating) and this package provides functionality you would otherwise build — re-implementing it costs more than a version bump.
• You already depend on the v1.x line and the Nova 4 migration is on your roadmap; upgrading keeps you on a maintained branch instead of a frozen one.
• You need a maintainer who tracks Nova's major releases promptly. Shipping a Nova 4-compatible major version is a reasonable signal of active maintenance.
• The scope of the package is narrow and inspectable enough that you can evaluate the diff yourself.

Look elsewhere or defer if:

• You are still on Nova 3. v2.0.0 does not serve you. Pin to v1.x and confirm with the maintainer that the 1.x line will receive fixes — a major-version pivot to Nova 4 often coincides with quietly dropping 1.x support.
• You are not using Nova at all. This is Nova-specific tooling; the release notes offer no evidence of framework-agnostic value.
• The release is genuinely just a compatibility bump. "Upgrade to nova 4" with no accompanying detail suggests no new capabilities, no deprecations beyond the Nova 3 drop, and no migration tooling. If you were hoping for features, this is not that release.
• Your team cannot absorb a coordinated major bump (composer constraint changes, Nova license upgrade, regression testing of admin surfaces) in the current cycle.
• You need evidence of migration support. With only this changelog line, there is no upgrade guide, no list of breaking API changes, and no stated deprecation timeline. Teams running v1.x in production should not treat this as a drop-in upgrade.

Due diligence before committing: confirm the Nova 4 minimum version supported, whether v1.x is still patched, whether the public API changed beyond Nova internals, and whether the package's license and Nova's licensing terms are compatible with how you ship.

How to Pitch It (Stakeholders)

For executives: This is a maintenance release that brings an internal admin-panel package onto Laravel Nova 4. It does not add user-facing features or new revenue capability. Its value is defensive: it keeps a dependency on a supported branch, removes a blocker from the Nova 4 upgrade, and avoids a future forced migration under time pressure. The cost is a coordinated version bump — composer constraint changes, Nova license alignment, and regression testing of admin screens. If we are already planning a Nova 4 move, fold this into that work rather than running it as its own project. If we are not, there is no reason to take this release now.

For engineering: Treat v2.0.0 as a major version with breaking changes by definition — the Nova 3 → 4 jump is not incremental, and the release notes give us one line to work from. Before we merge: read the actual diff, confirm the Nova 4 version floor, verify whether the 1.x branch is still receiving security fixes (this determines our fallback plan), and check for API changes that affect our own integration points, not just Nova internals. Plan a staged rollout with a rollback pin to v1.x. We should also expect thin documentation and budget time accordingly. If the diff turns out to be limited to Nova API compatibility shims with no behavioural change, say so explicitly in the PR — that changes the test scope considerably.

Recommendation: Conditional adoption. Merge into an already-planned Nova 4 upgrade; do not initiate a Nova upgrade solely to consume this release. Request an upgrade note and a 1.x support statement from the maintainer before we commit either way.

Note: this assessment rests on a single-line changelog with no prior evaluation on file. The build-vs-buy and risk positions above are reasoned from the Nova 4 compatibility signal, not from inspection of the package source, and should be re-validated once the diff and documentation are available.