Filament Mermaid Field Laravel Package

Product Decisions This Supports

Release signal: 3.0 is a compatibility release — the package now targets Filament 5. It is not a feature release, and the version bump to a new major tells us the maintainer treats Filament compatibility as a breaking contract rather than a soft dependency. That single fact drives most of the PM decisions below.

• Admin/back-office roadmap sequencing. If admin tooling is on the roadmap, our Filament version becomes a hard dependency for this package. Filament 5 adoption and this package's 3.x adoption should be planned as one workstream, not two — otherwise we own an unsupported combination.
• Build vs. buy for admin surface area. A maintained plugin that tracks Filament majors is a signal to buy rather than build custom admin glue. If we instead hand-roll this functionality, we take on the Filament upgrade tax ourselves every major cycle.
• Upgrade-window planning. Decide explicitly whether we ride the current Filament major (stay on this package's 2.x line) or move to Filament 5 (adopt 3.0). Both are defensible; drifting between them is the expensive option.
• Support-matrix commitment. For anything customer-facing or long-lived, this sets the expectation that we pin Filament + this package as a tested pair and re-validate on each major, rather than allowing floating constraints in composer.json.
• Vendor/concentration risk. A plugin whose versioning is bound to a third-party UI framework inherits that framework's release cadence, deprecations, and breaking changes. Worth tracking as a named dependency risk if admin is business-critical.

What this release does not tell us: whether any new capability shipped, whether older majors remain supported, or how large the Filament 4 → 5 delta is in practice. Those should be resolved before we commit a timeline.

When to Consider This Package

Consider it when:

• We are building or already run a Filament-based admin panel and need this capability rather than a bespoke implementation.
• We can commit to the same Filament major the package supports, and we are willing to upgrade the two together.
• The package is actively tracking upstream majors — as this release suggests — so we are not inheriting an abandoned dependency at the next Filament bump.
• The functionality is peripheral to our product differentiator; admin-panel tooling is usually buy, not build.

Look elsewhere when:

• We are on Filament 4 or earlier and cannot move soon. Adopting 3.0 is likely a breaking change for us; verify whether the previous major line still receives fixes and security patches, and for how long.
• The upgrade path is undocumented. If there is no migration guide for 2.x → 3.0, budget the upgrade as unknown-effort engineering work.
• We need a stable, slow-moving dependency. A package that majors in lockstep with a UI framework will generate recurring upgrade work by design.
• The capability is core to our product. Framework-coupled plugins are a poor home for differentiators — the framework's roadmap, not ours, sets the pace.
• We cannot verify Filament 5's own maturity. Confirm Filament 5 is production-ready for our risk tolerance before treating 3.0 as the safe default.

Immediate diligence before adoption or upgrade: confirm the package's Filament version constraint, whether 2.x remains maintained, whether a 2.x → 3.0 migration guide exists, and whether our own Filament version is compatible today.

How to Pitch It (Stakeholders)

For executives: The package we use for admin-panel functionality has shipped a new major version whose only stated change is support for the newest release of Filament, the framework it plugs into. This is housekeeping, not new capability — the maintainer is keeping pace with the platform. The practical consequence is a small, plannable piece of work: whenever we move to the new Filament version, this package moves with it. The main risk is scheduling, not technology — if we upgrade one without the other we end up on an unsupported combination. Recommendation: treat the Filament upgrade and this package's upgrade as a single ticket, size it, and slot it into the roadmap rather than letting it surface as unplanned maintenance. Low strategic risk, modest and predictable effort.

For engineering: This is a compatibility-only major, so the version bump exists to signal a changed Filament dependency, not new behaviour. Before we estimate: confirm the exact Filament constraint in 3.0, confirm whether 2.x still gets fixes and for how long, and check for a migration guide. Then decide pinned-vs-floating — I'd prefer we pin Filament and this package as a tested pair. If we're not ready for Filament 5, we stay on 2.x and record that as a known temporary position with a review date, rather than leaving it implicit. Flag any place where our code reaches into the plugin's internals; that's where a compatibility bump is most likely to actually bite.