Nova Busy Resource Field Laravel Package

Product Decisions This Supports

• Build vs. buy / keep vs. replace: v2.1.0 bundles a maintenance wave with dependency refreshes and CI alignment. That is a credible "actively maintained" signal, supporting a decision to keep buying rather than forking or replacing the component.
• Roadmap sequencing: There is no intended public API change and no new runtime configuration. Engineering effort therefore goes to platform upgrade work (Laravel 12 / PHP 8.3–8.4) rather than to integration rework or feature migration — plan the bump inside an existing sprint, not as a standalone migration epic.
• Platform modernization planning: The package now targets Laravel 12 and PHP ^8.3|^8.4. Treat this as an input to your own framework-upgrade timeline. If your product is still on Laravel 10/11 or PHP ≤8.2, this package becomes a forcing function with a deadline attached.
• Upgrade-cost estimation: No new config keys, no breaking API change, and a two-step upgrade path (constraint bump + asset rebuild) means near-zero product risk. Useful when negotiating scope or justifying a low-effort dependency ticket to stakeholders.
• Vendor due diligence / procurement: Consistent patch-level maintenance and stack modernization is a positive health indicator when renewing, adopting, or comparing against alternatives.

When to Consider This Package

• Strong fit if your stack is on Laravel 12 with PHP 8.3/8.4, or you have a committed plan to get there — this release assumes that baseline.
• Strong fit if you value a component that ships compatibility upkeep in step with the ecosystem, reducing long-tail upgrade debt across your dependency tree.
• Defer or look elsewhere if you are on Laravel 10/11 or PHP ≤8.2 with no near-term upgrade path: you would be pinning to an older major and absorbing support risk.
• Do not adopt on feature grounds alone. This release adds no features, no new configuration surface, and no API extension. Confirm v2.x already covers your requirements before reading maintenance activity as product momentum.
• Look elsewhere if you need an explicit LTS window or a published deprecation policy — the notes do not state one.

How to Pitch It (Stakeholders)

Executives: The vendor shipped a maintenance release: no API changes, no new configuration, no migration work. It modernizes the supported stack to Laravel 12 and PHP 8.3/8.4. Risk is low and it confirms the component is actively maintained, so we can hold our build-vs-buy position and fold the version bump into routine dependency hygiene. The only real decision is scheduling our own Laravel/PHP upgrade — if we stay on older versions, we should expect to pin and accept support risk.

Engineering: Bump the constraint to ^2.1 and reinstall Composer dependencies; rebuild package frontend assets if you mirror them locally. No runtime config keys were added and no API changes are intended, so there is nothing to refactor. Validate on PHP 8.3/8.4 with Laravel 12 in a branch before rollout, and confirm CI and tests already match the supported stack.