Product Decisions This Supports
- Upgrade sequencing and platform alignment. v3.0.0 hard-depends on Filament v5. This is fundamentally an admin-panel platform decision, not a feature decision: it ties your product's roadmap to Filament's major-version cadence, and every Filament v5 migration (theming, API changes, Livewire/PHP version floors) becomes a prerequisite for consuming anything this package ships next.
- Build vs. buy for admin/back-office surface. Packages in this tier exist to remove weeks of custom CRUD, form, and table scaffolding from your roadmap. The Filament v5 jump is the moment to re-run that buy-vs-build math: if your team was already planning to standardize on Filament v5, this release is close to free; if you're staying on v4, the calculus shifts toward forking or waiting.
- Feature gating and release planning. Nothing in v3.0.0 is a user-facing feature — it's an ecosystem-compatibility release. Treat it as a maintenance line item ("keep admin tooling current") rather than a roadmap input, and don't market it internally as a capability gain.
- Support-matrix obligations. Once adopted, you inherit responsibility for a Filament v5-only support window. That constrains which client environments, legacy PHP/Laravel versions, or older Filament-based internal tools your product can still serve.
- Vendor/OSS concentration risk. A single-maintainer package (as evidenced by the release attribution) that gates its major versions on a specific upstream major is a dependency-health line item worth tracking in your risk register for the admin layer.
When to Consider This Package
Adopt when:
- Your product already runs, or has a committed plan to run, Filament v5 — this release is explicitly built for that world.
- You need admin/back-office capability (resource CRUD, forms, tables, panel UX) and would otherwise build it in-house from Laravel primitives.
- You can absorb a coordinated upgrade: pinning, migration testing, and a QA pass on existing admin screens.
- The functionality is non-differentiating — internal tooling and operational surfaces where a maintained package beats bespoke code every time.
Look elsewhere or hold when:
- You are on Filament v4 or earlier with no near-term upgrade path. v3.0.0 is a breaking release with no announced compatibility shim; staying put means pinning to the prior major and accepting an eventual support gap.
- Your admin layer is customer-facing and differentiating — a hard dependency on an upstream major's release cycle is a poor fit for surfaces you need to control tightly.
- You have hard version constraints (older PHP/Laravel, regulated environments with slow dependency churn) that don't align with Filament v5's floors.
- The package is load-bearing and lightly maintained — a breaking release with a single contributor and no published migration guide is a signal to fork or evaluate an in-house alternative before you commit.
How to Pitch It (Stakeholders)
For executives: This is a housekeeping release, not a product release. The package we use for internal/admin tooling has moved to v3.0.0, and its only change is that it now requires Filament v5 — the newer major version of the admin framework it plugs into. There is no new capability and no user-visible change. The decision on the table is purely when, not whether or how much: adopting it means scheduling an admin-panel upgrade, and deferring it means we pin to the older major and carry a small amount of technical debt until we're ready. Cost is engineering time, not licensing, and the work is bounded and well-understood.
For engineering: v3.0.0 is a single breaking change — the Filament v5 upgrade — with no other feature, fix, or deprecation content in the release. That means the risk surface is entirely the Filament v4 → v5 migration itself, which sits upstream of us and is not something we can partially adopt. Recommended approach: pin explicitly to the v2 line if we aren't ready; if we are, branch, upgrade Filament first, then bump this package, and run the full admin-suite regression (panels, resources, forms, tables, auth/policies) before merge. Because the package's changelog gives us no migration guidance of its own, budget exploratory time for API drift we discover at integration rather than from documentation. Flag the single-maintainer/single-upstream-major dependency as a standing risk; if the admin layer grows more central, we should revisit a fork or an in-house fallback.