Voyager Extension Laravel Package

Product Decisions This Supports

• Upgrade sequencing / platform roadmap. The headline is Laravel v10 support. If our app is on Laravel 9 and Laravel 10 is on the roadmap, this package is no longer a hard blocker — that's the single most decision-relevant line in the release. It converts "we can't upgrade until this dependency catches up" into "we can schedule the upgrade."
• Voyager version strategy. Adding Voyager v1.7 support lets us bump the admin layer and this addon together rather than holding the admin panel back. Decide explicitly whether Voyager 1.7 is a target or just tolerated; this release keeps the option open either way.
• Build vs. buy for back-office CRUD. For teams already running Voyager, this is a buy decision for admin UI surface area (BREAD-style CRUD, admin widgets) instead of custom Laravel scaffolding. Each compatibility release like this extends the amortization window on that original bet.
• Stack consolidation vs. migration. It informs — but does not settle — the "stay on Voyager or move to Filament/Nova" question. A maintenance release that keeps a legacy admin stack viable is an argument for deferring migration, not for expanding investment in it.
• Risk budgeting. Version 0.95.84 signals pre-1.0, high-cadence patch releases with no semver guarantee. That's a planning input: pin the version, budget regression testing on every bump, and avoid building differentiating product logic on top of this package's internals.

When to Consider This Package

Adopt / keep it when:

• You are already on Voyager (especially 1.7) and need to reach or maintain Laravel 10 without ripping out the admin layer.
• The need is internal back-office CRUD, content management, or rapid admin scaffolding for a small-to-mid Laravel app.
• You can pin versions, run a test suite against upgrades, and absorb frequent patch releases.
• The team accepts owning vendor risk for a niche addon with a single-maintainer profile.

Look elsewhere when:

• Greenfield project. Prefer Filament or Nova — Voyager's ecosystem momentum is limited, and starting on it means inheriting the same migration question later.
• You need Laravel 11+ or a modern PHP 8.2/8.3-only baseline; this release states Laravel 10 and says nothing beyond it.
• You require an SLA, long-term support commitments, or audited security response.
• The admin surface is complex or differentiating (multi-tenant authorization, custom workflows, heavy audit requirements) — pre-1.0 tooling is a poor foundation there.
• You are not already on Voyager. Compatibility with Voyager 1.7 is only valuable if Voyager is a sunk cost you're protecting.

Caveats on this assessment: the release notes are three lines with no linked changelog, migration notes, or dependency diff. Treat "Minor fixes" as unverified until the dependency graph and test suite confirm it.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a routine maintenance release, not a strategic bet. It does two useful things: it confirms the package works with Laravel 10 and Voyager 1.7, which removes a known blocker on our framework upgrade path, and it signals the maintainer is still active. The cost to act is low — a short upgrade-and-test spike. The recommendation is to take the upgrade, keep the dependency version-pinned, and not treat this as justification for deepening our investment in the Voyager admin stack. The longer-term question of whether Voyager remains the right admin layer is unchanged and should be evaluated on its own timeline.

For engineering (short brief): Laravel 10 and Voyager 1.7 compatibility landed in v0.95.84, alongside unspecified minor fixes. Validate on a branch: bump the package and Voyager together, check transitive dependency constraints, run the admin smoke tests plus any custom BREAD definitions. Because the package is pre-1.0, assume no semver guarantees — pin the exact version, read the diff rather than the notes, and capture any patched internals we depend on so the next bump isn't a surprise.