Flux Radial Laravel Package

Product Decisions This Supports

• Framework upgrade planning (primary). v1.1.0 is a compatibility-only release: the sole change is Laravel 13 support. That makes this package an upgrade gate rather than a feature input — it belongs on the Laravel 13 readiness checklist, not the product roadmap. Track it as a "must be green before we bump the framework" line item.
• Build vs buy. The package is early-stage (v1.x line, single maintainer, two releases total) and its latest changelog contains no functional changes. That's enough to justify buying it for a non-differentiating capability and not enough to justify building product-critical logic on top of it. Keep the integration behind a thin adapter/interface so a swap is a contained change.
• Roadmap sequencing. There is no functional velocity to plan against here — no new features, no deprecations, no behavioral changes in this release. Do not schedule dependent feature work on the assumption of an active feature roadmap from this maintainer.
• Use cases. Appropriate where the package is an accelerator on internal tooling or a non-critical surface. Inappropriate as the sole mechanism for a customer-facing, revenue-path capability until it has more release history behind it.

Note: this assessment is derived from release metadata only (v1.0.0 → v1.1.0). It should be revisited once we have hands-on spike results or a fuller changelog.

When to Consider This Package

Consider it when:

• You are on Laravel 11/12 and moving to Laravel 13 — v1.1.0 keeps this dependency on the supported path, so it won't block the upgrade.
• The capability it provides is commodity, not differentiating.
• Its public API is small enough to wrap behind your own abstraction in an afternoon.
• The maintainer demonstrably tracks Laravel majors promptly. Shipping Laravel 13 support in the first follow-up release is a positive, if single-data-point, signal of maintenance responsiveness.

Look elsewhere when:

• The package would sit on a critical path or a security-sensitive surface. One maintainer with no stated SLA or security policy is a continuity risk you should not underwrite for those workloads.
• You need a published deprecation and support policy, or release notes detailed enough to assess behavioral risk. This release is compatibility-only, which tells you nothing about feature maturity or how breaking changes will be communicated.
• A first-party or larger-community alternative exists at comparable effort.
• Your team is not yet on Laravel 13 and you need a reason to adopt now — there is none in this release. Defer until the upgrade forces the decision.

How to Pitch It (Stakeholders)

For executives: We depend on a small, low-cost Laravel package that just shipped Laravel 13 compatibility. The good news is the upgrade risk is low and we are not blocked on the framework move. The watch item is continuity: it is maintained by a single person with a short release history, so we are treating it as a replaceable utility, keeping our integration thin, and pinning the version. No budget or headcount ask.

For engineering: Bump to v1.1.0 as part of the Laravel 13 upgrade, not as a standalone change. The changelog lists only the framework-support PR, so assume no API contract changes but verify against our usage in CI before merging. Pin the version, add the repo to the dependency watchlist for major-version and abandonment signals, and keep all calls behind our existing wrapper so a future swap is a single-file change.