Laravel Natural Language Laravel Package

Product Decisions This Supports

• Platform roadmap alignment. v8.0.0 targets Laravel 10 with a PHP 8.1 floor. If our roadmap already calls for Laravel 10 / PHP 8.1 migration, this release lets us sequence the package upgrade alongside the framework upgrade rather than blocking on it.
• Build vs. buy / dependency strategy. A major version bump signals the maintainer is actively tracking current framework releases. That is a positive signal for keeping this as a bought dependency rather than re-implementing its capability in-house.
• Upgrade planning and effort sizing. Major version = breaking changes. This is a scoping input for the next sprint/quarter: allocate regression testing, changelog review, and a rollback plan before committing.
• Feature/use-case enablement. Adopting v8 unlocks the package on our target platform, so any product features we deferred pending Laravel 10 support can be re-evaluated.
• Support-window and risk management. Dropping older PHP/Laravel versions means older branches stop receiving fixes; this informs our security-patch and EOL exposure decisions.

When to Consider This Package

Consider adopting/upgrading when:

• We are on (or committed to) Laravel 10 and PHP 8.1+ — this release is built for that baseline.
• We need the package's capability and want a dependency that is actively maintained against current framework versions.
• We can absorb a major-version migration (breaking changes expected; API/config review required) within the current planning cycle.

Look elsewhere or defer when:

• We are still on Laravel 8/9 or PHP < 8.1 — v8 will not run; we would need to pin an older major and accept a reduced support window.
• The capability is core/strategic enough that vendor lock-in or a future major-version surprise is unacceptable.
• We cannot fund the regression testing a major bump requires this cycle; a staged upgrade behind a feature branch is the safer path.

How to Pitch It (Stakeholders)

To executives: This is a routine major-version upgrade of an existing dependency. The headline is alignment: the package now supports Laravel 10 and requires PHP 8.1, matching where our platform is heading. The cost is bounded engineering time for testing; the benefit is staying on a maintained branch and avoiding EOL/security exposure. Recommend approving the upgrade as part of the Laravel 10 migration workstream rather than as a standalone project.

To engineering: v8.0.0 is a breaking release — Laravel 10 support and a PHP 8.1 minimum. Plan for a changelog/upgrade-guide review, dependency and config changes, and a full regression pass on affected flows. Gate the merge behind CI on PHP 8.1+ and Laravel 10, with a documented rollback to the prior pinned major.

Caveat: The release notes are terse (two bullet points). Before committing, we should confirm the package identity/version line, read the full upgrade guide for breaking changes beyond the platform floor, and verify our other dependencies also support Laravel 10 / PHP 8.1 so we don't trade one blocker for another.