Rhea Laravel Package

Product Decisions This Supports

• Framework upgrade planning: v2.1.0 adds Laravel 11 support, which converts "blocked on Laravel 11" into a schedulable upgrade task. If Laravel 11 is on the roadmap (or already mandated by a security/patching policy), this package is no longer a dependency-level blocker.
• Build vs. buy for UI scaffolding: The package is a TALL-stack (Laravel/Blade/Livewire/Alpine) building block within the Lara Zeus family. The buy case rests on not hand-rolling the same UI/data plumbing in-house; decisions to keep, wrap, or replace it should be made against the cost of maintaining that scaffolding internally.
• Roadmap sequencing: This is a compatibility-only release — no new features, no deprecations, no breaking changes. That means it should not trigger a feature roadmap re-plan; it only opens an upgrade lane for teams pinned to Laravel 10.
• Risk/exit decisions: Minor releases like this are a useful proxy for project health (maintainer is responsive to upstream framework releases). Continued single-maintainer cadence is the counterweight when weighing "stay" vs. "abstract behind our own interface for later replacement."
• Release cadence and freeze windows: Safe to absorb during routine maintenance because the change surface is low (compatibility plus CI tooling bumps); no data migrations or config changes implied by the notes.

When to Consider This Package

Adopt when:

• You are standardizing on Laravel 11 and want a UI layer that explicitly declares support for it.
• You are already inside the Lara Zeus ecosystem (or accept its conventions) and want the Blade/Livewire pieces to compose with the rest of the family.
• You value a packaged convention over bespoke implementation, and the feature scope matches your needs without heavy forking.

Look elsewhere or proceed cautiously when:

• You need vendor-backed SLAs or guaranteed long-term support; this is a single-maintainer open-source project.
• You are on Laravel 12+ or an unsupported PHP/framework combination — the release notes show support tracking to Laravel 11 only.
• Your needs diverge from the package's UI opinions and you would end up forking, which erodes the buy case.
• You require a documented deprecation/upgrade policy — the notes are a changelog and dependabot traffic, not a compatibility matrix.

How to Pitch It (Stakeholders)

For executives: A dependency we rely on for UI components just released a maintenance update that adds support for Laravel 11. It is a low-risk, non-breaking change that removes a blocker to our framework upgrade rather than adding new functionality. Adopting it costs a routine composer update; the strategic value is keeping our platform upgrade path open and avoiding an unsupported framework pin. Principal risk remains supplier concentration — one primary maintainer — which we mitigate by keeping our usage thin and documented.

For engineering: v2.1.0 is minor and additive: Laravel 11 support plus dependabot bumps to the Composer install action and the metadata-fetch action. No breaking changes, no deprecations, no config or migration surface. Recommended action: bump the constraint, run the suite on Laravel 11 in a branch, and treat the CI action bumps as no-op noise. Note there is no functional delta in this release, so no feature work should be scheduled off the back of it.