Filament Redirects Laravel Package

Product Decisions This Supports

• Platform upgrade sequencing. The v3.0.0 release is a compatibility release: it targets Filament 5 / Laravel 13. That makes this package a named dependency on our Laravel 13 upgrade critical path — if we want Laravel 13, this package must move to v3 in the same window.
• Roadmap timing. Treat the Laravel 13 / Filament 5 migration and this package's v3 upgrade as one epic, not two. The package's release cadence now effectively gates our ability to adopt the newest framework major.
• Build vs buy. A maintained third-party package that ships framework-major support promptly is doing maintenance work we would otherwise absorb ourselves. If the alternative is building equivalent admin-panel functionality in-house on Filament, this release is evidence in favour of buying/keeping rather than building.
• Version pinning and support policy. A major bump implies breaking changes and an implicit support boundary: v3 for Filament 5 / Laravel 13, v2 for the previous generation. That is a decision about how long we can stay on our current stack without forking or paying for backports.
• Risk register entry. The only signal in this release is a single compatibility line. That tells us the maintainer is responsive to framework majors, but it tells us nothing about feature direction, deprecation policy, or long-term support commitments — worth logging as an open dependency risk rather than closing it.

When to Consider This Package

Adopt when:

• We are on, or committed to, Filament 5 / Laravel 13 and need this capability in the admin surface.
• We want the capability without owning its maintenance, and the package's scope is adjacent to — not core to — our differentiation.
• We value a maintainer who tracks framework majors promptly; the v3 release is direct evidence of that.

Look elsewhere or wait when:

• We are still on Filament 4 or Laravel 11/12. v3 is a breaking major; upgrading it in isolation buys nothing and risks an unsupported combination. Either upgrade the stack or stay on v2.
• We need a predictable long support window. A package that appears to move forward with each framework major, without a stated LTS or backport policy, will force repeated migrations.
• The capability is core to our product and maintainer concentration (bus factor) is a concern.
• We need enterprise support, SLAs, or a documented deprecation path.

Questions to answer before committing:

1. What actually breaks between v2 and v3 beyond framework version constraints?
2. Will v2 receive fixes (security at minimum), and for how long?
3. Is there a changelog, test matrix, or upgrade guide, or only this one-line note?
4. What is the licence and maintenance model?

How to Pitch It (Stakeholders)

For executives (30 seconds): One of the packages in our admin-panel stack has released a version compatible with the next Laravel and Filament major releases. It is a compatibility release, not a feature release — no new spend, no new capability. Its value is that it removes a blocker from our platform-upgrade plan; its cost is that it ties our upgrade timing to this package's release schedule.

For engineering (the working summary): v3.0.0 is a major version bump whose stated change is Filament 5 / Laravel 13 support. Assume breaking changes from the major bump. Plan the v3 upgrade inside the framework-upgrade epic and pin v2 until we move the stack. Before scheduling, get the v2→v3 diff and confirm whether v2 gets backported fixes; a one-line release note is a compatibility signal, not sufficient basis for a go/no-go date.

The honest caveat to state up front: this assessment rests on a single line of release notes. It tells us the package is alive and tracking framework majors. It does not tell us what else changed in a major version. Confirm the upgrade surface with engineering before it appears on a roadmap as committed work.