Resources Laravel Package

Product Decisions This Supports

• Adopt vs. reject — the only live decision. v3.2.0 formally marks orchestra/resources as DEPRECATED and pins support to Laravel ~5.2 (PHP ~5.6–7.0). There is no feature surface to evaluate against the roadmap. The PM's deliverable is an explicit, recorded "no-adopt" call so the question isn't quietly reopened by an engineer who finds the facade convenient.

• Roadmap framing: migration, not feature. If the package is already in the stack, it generates exactly one backlog item — contain and remove. It belongs on the roadmap as deprecation-driven risk reduction with a dated exit, bundled with the next framework upgrade, not as a standalone package swap or an enhancement.

• Platform currency strategy. The illuminate/*: ~5.2 constraint is a ceiling on the whole upgrade program, not a single dependency. Any PHP 8 jump, shared-library adoption, static-analysis or test-tooling upgrade, or new service will collide there. Sequence framework upgrade and package replacement as one body of work and treat this package as the thing defining the ceiling.

• Scope control in discovery. Nothing user-facing is unlocked by this release — it ships a deprecation notice plus a namespace convenience (Orchestra\Resources\Facade replacing the soon-to-be-removed Orchestra\Support\Facades\Resources). Keep it out of feature scoping; legitimate product actions are remove, contain, or freeze.

• Risk acceptance requiring product sign-off. Running an unbounded EOL dependency — no security patches, no vendor support, a shrinking hiring pool — is a risk-acceptance decision, not an engineering preference. A PM should own that acceptance explicitly, name it in the risk register, time-box it, and attach an exit date. Letting it drift is the only wrong answer.

• The explicit fork. Either (a) contain for a short defined window — pin the exact version, commit composer.lock, stand up a private Composer mirror/satis, normalize facade references, and wrap the facade behind an application-level adapter — or (b) exit — reimplement the resource-layer behavior with native Laravel resource controllers, route model binding, and container bindings on a supported framework, and drop the dependency as part of the framework jump. The PM chooses out loud and funds it.

When to Consider This Package

The adoption threshold is inverted: only if there is no alternative.

• Legacy maintenance only. You already run it inside a Laravel 5.2 / Orchestra Platform-era application and need a low-risk way to keep the existing install functional while a funded replacement is designed. This is containment, not adoption.

• The single actionable item is the facade rename. If you stay temporarily, move all references from Orchestra\Support\Facades\Resources to Orchestra\Resources\Facade now, and update the config/app.php alias. Budget days of maintenance work, not a project — doing it early turns a future upstream removal into a non-event. On 5.2 there is no auto-discovery, so provider and alias registration stay manual.

• Walk away in every other case: new projects, any framework version beyond 5.2, customer-facing or revenue paths, PII-handling or security-sensitive surfaces, anything requiring a multi-year support horizon, and any team without engineers fluent in Laravel 5.2 idioms. Note that with zero dependents and a narrow registry/facade surface, this package is usually scaffolding rather than a system of record — confirm what it actually touches in your codebase, because if it isn't load-bearing the exit is cheaper than it looks.

• Additional walk-away conditions: you cannot establish a private Composer mirror (upstream can delete the repo or Packagist entry, breaking builds), or you cannot secure explicit risk-acceptance sign-off for EOL runtimes. Both are prerequisites, not nice-to-haves.

• The one guardrail if you do stay: keep the facade out of controllers, views, jobs, and Blade templates. Route everything through a thin application-level adapter and depend on that class, so the eventual replacement touches one file instead of every call site — and so the adapter can later delegate to native Laravel without application code changing.

How to Pitch It (Stakeholders)

For executives: The maintainer has marked this package deprecated and constrained it to Laravel 5.2, a framework that has been end-of-life for years. Practically that means no security patches, no compatibility with current Laravel, no vendor or community support channel, and a shrinking pool of engineers who can work on it — risk that compounds every quarter we keep it. This release adds no product capability: it is a deprecation notice plus a small internal namespace change. I recommend approving a scoped migration off the package, bundled with the next framework upgrade, with a dated exit rather than continued investment. In the interim we freeze the version, mirror the artifacts so builds cannot break, and take explicit, time-boxed risk acceptance with a named owner.

For engineering: v3.2.0 ships no features. It formally deprecates the project, pins support to Laravel ~5.2, and introduces Orchestra\Resources\Facade as the replacement for Orchestra\Support\Facades\Resources, which is scheduled for removal. Actions: (1) inventory every call site and both facade namespaces, including config/app.php aliases; (2) move imports and aliases to the new facade now, and clear config/autoload caches after; (3) wrap the facade behind a thin application-level adapter and register resources in a dedicated service provider so removal touches one class; (4) pin the exact version, commit composer.lock, and stand up a private mirror/satis; (5) open a ticket to reimplement the resource layer as native Laravel resource controllers and routing on a supported version, and remove the package as part of the framework upgrade. Capture how resources are registered and resolved before the last engineer familiar with these conventions leaves — documentation for this package is thin and will not improve.