Product Decisions This Supports
- Whether "what shipped?" becomes self-serve or stays an interrupt routed to engineering. This package renders a changelog timeline and a per-user "what's new" modal inside the Nova admin panel your support, success, and onboarding audiences already live in. The decision it unlocks is a support-cost one: count the weekly "what changed?" pings to engineers × average time-to-answer, and weigh that against a one-to-two-day build. That framing converts a cosmetic card into a measurable line item — and gives you a clean kill criterion if nobody opens it.
- Build vs. buy, resolved decisively toward "buy the pattern, own the code." The evidence is unambiguous: 20 stars, 0 dependents, archived since 2020-09-12, a single v1.0.0 release, and an opportunity score (5.27) sitting far above the overall score (0.295). That gap is the PM case — a genuinely useful idea with abandoned execution. MIT licensing means the real choice is fork or reimplement, never adopt as a maintained dependency. Scope it as an in-house Nova card with this repo as the written spec.
- Roadmap input that exposes an upstream gap. If the team cannot answer "what changed in the last deploy?" from inside the product, release notes aren't the problem — release hygiene is. Committing to a changelog surface forces the absence of a consistent
CHANGELOG.md, versioning discipline, or a release source of truth into the open. Budget that work explicitly; otherwise the card only renders the unreliability more visibly, and a stale "what's new" panel erodes trust in the whole admin surface.
- Sequencing input on the next Nova upgrade. Viability is bounded by the Nova major. On Nova 2/3 it is a plausible frozen stopgap; on Nova 4+ (PHP 8 / Laravel 8+) a package last shipped in September 2020 is near-certainly incompatible, and there will be no compatibility release. Book the build-vs-fork call before the upgrade window, with a one-day spike as the input — not after the card silently goes blank in production.
- A cheap, falsifiable experiment. Stand it up behind an admin-only permission gate for a small pilot cohort, instrument whether support/success actually open it, and retire it if they don't. Low build cost, observable outcome, no customer-facing blast radius.
- Use cases to scope against: internal changelog viewer for support and success; onboarding aid for new engineers ("here's what moved recently"); a template for a client-facing "what's new" panel; and a forcing function to standardize release notes upstream.
When to Consider This Package
Consider it — realistically, vendor or fork it as a blueprint, not as a dependency — only when all of the following hold:
- We already run Laravel Nova (a paid first-party product). Without Nova this isn't evaluable; it is simply not adoptable. The marginal UI cost and styling work are near zero only because Nova already exists.
- The need is a read-only display of release notes. That is the entire feature surface. It is not a CMS, not an announcement system, not a customer-facing marketing changelog with scheduling, segmentation, or localization. If any of those words appear in the requirements, stop.
- We accept ownership. Archived upstream means no security patches, no issue triage, no Nova compatibility fixes. Somebody internal must own the code, the runbook (source location, cache-refresh command, permission gate), and a review date. Twenty stars and zero dependents means no community to fall back on — knowledge concentration is the real operational risk.
- A release source of truth already exists. GitHub Releases with a token and aggressive caching, or a disciplined
CHANGELOG.md for monorepos and hand-versioned repos. An hour-long cache is the floor; unauthenticated GitHub API allows 60 requests/hour per IP, and a shared egress IP will exhaust that in an afternoon. Errors must render as a distinct state from "no releases," or the panel quietly lies.
- The estate is on a Nova version this can actually run against — or there is appetite for a one-day spike to confirm it. Verify the Laravel/PHP floor and the real class names against
src/ and the lockfile; the docs are the weakest part of this package and prior write-ups may not reflect the actual composer.json.
- Markdown rendering is trusted or sanitized. Release bodies render as HTML inside an authenticated admin page. If the source is ever less trusted than your own repo, verify or wrap the renderer so raw HTML is stripped. It's the one supply-chain-adjacent risk in an otherwise cosmetic package.
Look elsewhere when: there is no Nova license; the requirement is customer-facing or multi-audience; you need a maintained dependency with an upgrade path; the roadmap includes a Nova 4/5 migration inside the next two quarters; or nobody will own a fork. In those cases the honest answer is "reimplement as a small in-house card" — the feature is a fetch, a cache, and a Blade view, and that is cheaper than inheriting abandoned code.
How to Pitch It (Stakeholders)
To executives — one paragraph. Engineers field repeat questions about what shipped, every week, forever. This package proves the shape of a fix — a changelog inside the admin panel people already use — but the upstream project is archived, twenty stars, zero dependents, last release September 2020. We are not proposing we depend on it. We're proposing a one-to-two-day in-house Nova card built to the same spec, MIT-licensed source as reference, funded against the measured cost of those interruptions. Success is binary and cheap to observe: do support and success open it unprompted within a month? If not, we retire it and we've lost two days.
To engineering — the framing that matters. Treat this repo as a specification, not a dependency. composer require is the wrong verb; vendor into packages/ is the right one. The inheritance worth keeping is small and good: the v1.0.0 move to Laravel's HTTP client means the fetch path is Http::fake()-testable, which gives you a regression net from day one. The four extension points cover roughly 90% of what you'll want — publish and override views, publish and edit config, wrap the fetch in a cached service, gate visibility in NovaServiceProvider. Anything beyond that is a fork, and a fork should be renamed, vendored, registered with an owner and a review date, and treated as an in-house product with an upstream spec. Do not put it on the release critical path: warm the cache on a schedule, keep the fetch off any request that can fail a deploy, and never let a rate-limited call render as "nothing shipped."
The ask. One day to spike compatibility against our Nova major, one to two days to build or fork, one named owner, and a one-page runbook. The alternative — a frozen 2020 package silently white-screening after the next Nova upgrade — costs more than the build and arrives with no warning.