Duration Laravel Package

Product Decisions This Supports

• Admin/back-office roadmap timing: v1.0.0 aligns the package with Laravel Nova 4, so any planned admin panel work should target Nova 4 rather than building new features on Nova 3. This is a forcing function for sequencing the admin roadmap.
• Build vs. buy for internal tooling: If the team is weighing custom admin screens against a Nova-based package, Nova 4 compatibility removes a maintenance objection and makes the buy/assemble path more defensible.
• Platform upgrade planning: The release implies a minimum stack (Nova 4, and by extension the PHP/Laravel versions Nova 4 requires). That constrains when other product work can ship and should be reflected in the platform upgrade epic.
• Support and lifecycle policy: A v1.0.0 tied to Nova 4 is a signal to decide whether the product supports Nova 3 and Nova 4 in parallel or drops Nova 3. That decision affects customers on older stacks and should be made explicitly, not by default.
• Use cases unlocked: Admin resource management, internal operations dashboards, and support/ops tooling for teams already standardized on Laravel + Nova.

When to Consider This Package

Consider it when:

• The application is on Laravel Nova 4 (or is committed to upgrading), on a PHP/Laravel version that Nova 4 supports.
• You need admin-panel functionality — resource CRUD, filters, actions, metrics — and want it delivered as a maintained package rather than bespoke code.
• You value a vendor/dependency that tracks Nova's major versions; staying on a Nova 3-only package means accumulating upgrade debt.
• The team already has Laravel/Nova expertise, so the integration cost is low.

Look elsewhere or defer when:

• You are still on Nova 3 and cannot absorb the Nova 4 upgrade (PHP/Laravel minimums, API changes in custom fields/tools). Treat this release as a breaking change for your stack, not a drop-in.
• You are not using Nova at all — the package's value is coupled to that ecosystem; a generic admin framework or headless approach may fit better.
• The product needs capabilities outside Nova's model (heavy custom workflows, non-Laravel services), where a separate admin application is the better boundary.
• Verify before adopting: confirm the package's actual feature surface, test coverage, maintainer activity, and license. The release note alone ("Upgrade to Nova 4") establishes compatibility, not maturity — a v1.0.0 with a single compatibility-driven release warrants a spike and a dependency review before it lands in a customer-facing path.

How to Pitch It (Stakeholders)

For executives: This release keeps a Laravel admin-panel dependency current with Laravel Nova 4. The business value is reduced maintenance and security risk on our internal tooling, not new customer-facing features. The cost is an upgrade project: Nova 4 carries minimum PHP/Laravel requirements, so teams on older stacks must plan the move rather than assume a free upgrade. Recommendation: fund the Nova 4 upgrade as a scheduled platform item, and decide explicitly whether we continue supporting Nova 3 customers.

For engineering: Treat v1.0.0 as a breaking change relative to any Nova 3 baseline. Confirm PHP/Laravel minimums, audit custom Nova fields/tools for API changes, and add integration coverage on Nova 4 before rollout. Because this is the package's first tagged release, also assess maintainer responsiveness and release cadence — pin the version, and have a fallback plan if the package stalls. Do not adopt on the strength of the changelog alone; run a short spike against a real admin resource first.