Laravel Docweaver Laravel Package

Product Decisions This Supports

• Framework upgrade planning. v5.1.0 adds Laravel 10 support and removes Laravel 8. This is a compatibility release, not a feature release — its product value is that it unblocks teams moving to Laravel 10 and gives a clear signal that the maintainers track upstream Laravel release and EOL windows rather than letting the support matrix drift.
• Support-matrix / EOL policy decisions. The drop of Laravel 8 is effectively a breaking change shipped on a minor version. Treat this as a maintenance-health data point: the package is actively maintained, but it expects consumers to stay within roughly the two most recent Laravel majors. That informs how much internal lead time to budget for framework upgrades before this dependency becomes a blocker.
• Build vs. buy. Continued upstream tracking reduces the "we'll have to fork it" argument and lowers total cost of ownership for a buy/adopt decision — provided your app is on Laravel 9+.
• Roadmap sequencing. If your platform roadmap includes a Laravel 9→10 migration, this release should be sequenced as a dependent task, not a standalone initiative. Upgrade the framework first, then pick up this package version.
• CI and test-matrix scope. If you test against multiple Laravel majors, this release tells you which combinations are worth keeping in the matrix and which can be retired.
• Compliance and security exposure. Staying on a package line that supports currently-patched Laravel versions reduces the surface area for "unsupported dependency" findings in security reviews.

When to Consider This Package

Adopt when:

• Your application runs Laravel 9 or 10 (or later, if the maintainers have added it — verify the composer.json constraint rather than assuming from this note alone).
• You want a dependency whose maintainers demonstrably respond to new Laravel majors within a reasonable window.
• You are willing to accept a policy where dropping an old framework major can happen on a minor release.

Look elsewhere, or plan mitigation, when:

• You are still on Laravel 8. This version excludes you. You can pin to 5.0.x, but that line should be assumed frozen and not receiving security or bug fixes — that is a short-term bridge, not a strategy.
• You need a formally stable support policy across many framework majors. A minor-version framework drop is a semver-discipline red flag worth raising with engineering; audit your composer constraint style (^5.0 will float you into this release) and pin deliberately.
• You are on Laravel 11+ or a very new major. This note does not cover it. Confirm support before committing; absence here is not evidence of absence, but it is not evidence of support either.
• You require a documented, dated deprecation window before compatibility is removed — the release notes as written do not provide one.

How to Pitch It (Stakeholders)

For executives: This is a routine maintenance release for one of our dependencies — it aligns the package with Laravel 10 and retires support for Laravel 8. There is no new functionality and no direct user-facing impact. The value is risk reduction: it keeps us on framework versions that still receive security patches and avoids an "unsupported dependency" finding at the next review. Cost is a small engineering task to confirm compatibility and upgrade the pinned version.

For engineering: The package now targets Laravel 10 and no longer supports Laravel 8. Before upgrading, verify our composer constraint and confirm our Laravel version. If we are on 8, we are cut off from this line and need an explicit decision — upgrade the framework, pin to the previous line with a dated exit, or fork. Also note the framework drop shipped on a minor version, so review whether our constraint floats us into breaking compatibility without a deliberate pin. Recommend a regression run on the affected integration points and a CI matrix update to drop Laravel 8 combinations.