Nova Publishable Laravel Package

Product Decisions This Supports

• Framework upgrade planning (Laravel 10 → 11): Release 1.2.0 adds Laravel 11 compatibility. This is the primary decision this release unlocks — it removes nova-publishable as a blocker on an L11 migration roadmap, provided the rest of the Nova/admin stack is also L11-ready.
• Build vs. buy for editorial scheduling: If the roadmap includes "schedule content to go live / come down at a specific time" in the Nova admin, this package is a candidate buy/borrow option rather than a bespoke trait + Nova field + scheduled-command build. Justify the decision on time-to-ship and maintenance cost, not on feature depth — publishing windows are a small, well-understood surface area.
• Nova-first admin strategy: This is a Nova-specific module. Adopting it is a soft commitment to keeping Nova as the admin layer; it is not portable to Filament, custom Blade admin, or headless CMS paths. Confirm the admin platform decision before adopting.
• Scope negotiation with stakeholders: Publishable windows are frequently conflated with a full CMS workflow (draft → review → approve → schedule). This package addresses the scheduling/primitives layer. If stakeholders expect approval chains, revision history, or multi-stage editorial workflows, scope those separately.
• Support-window policy: Any dependency that only adds framework compatibility reactively (i.e., L11 support arrives after L11's release) should be captured in your dependency support-window policy and upgrade-risk register.

When to Consider This Package

Consider it when all of the following hold:

• You are on Laravel Nova and intend to stay there for the foreseeable planning horizon.
• You need straightforward publish/unpublish scheduling on Eloquent models surfaced in Nova — not a full editorial workflow.
• You are on, or moving to, Laravel 11 (1.2.0 is the version that matters here; 1.1.0 and earlier should be treated as incompatible with L11).
• Your team accepts a small, single-maintainer module as a dependency and has a fallback plan (fork or in-house replacement) if maintenance lapses.

Look elsewhere (or build in-house) when:

• You are not on Nova, or Nova's future in your stack is undecided.
• You need approval workflows, multi-language publishing, content versioning, or complex audience segmentation — that is a CMS/workflow platform decision, not a package decision.
• Your procurement or security policy requires active multi-maintainer stewardship, a published security policy, or a guaranteed support SLA. The release shows a first-time contributor and no signal of a formal support commitment.
• You are pinned to Laravel 9/10 with no upgrade pressure — 1.2.0's only material change is framework compatibility, so it is not a reason to adopt on its own.

How to Pitch It (Stakeholders)

For executives: A small, low-cost module that gives editors the ability to schedule when content appears and disappears in our admin, instead of engineering building and maintaining that capability ourselves. Version 1.2.0 adds Laravel 11 support, which means adopting it does not block — and if already adopted, does not delay — our framework upgrade. Risk is contained: it is a narrow, replaceable component, and the fallback is a modest in-house build if the project stops being maintained.

For engineering: 1.2.0 is a compatibility-only minor release adding Laravel 11 support; no breaking changes, no API changes, no deprecations. Treat it as the minimum viable version for any L11 environment. Note the maintenance profile: single-repo module, new outside contributor, no stated support policy — vendor it behind our own interface or pin it with a fork plan so a lapse does not become an upgrade blocker. Confirm coexistence with our Nova version and content model conventions before wiring it into production resources.