Ad Search Bundle Laravel Package

Product Decisions This Supports

• Framework upgrade planning (highest-value use): v6.0.1 adds Symfony 7 support, which is the compatibility gate for Laravel 11+. This release is a direct input to the question "can we move our Laravel version forward without forking or replacing this dependency?" Treat it as an unblocker on the upgrade roadmap, not as a feature.
• Dependency risk / build-vs-buy: A release that removes a deprecated PHP function (utf8_encode, deprecated as of PHP 8.2) is evidence that the maintainer is tracking upstream deprecations rather than accumulating them. That lowers the "we'll have to maintain a fork" probability and biases the buy/reuse decision in the package's favour.
• Upgrade sequencing and release timing: This is a patch release (v6.0.1), so it should be safe in the existing constraint range — but if Symfony 7 support came at the cost of Symfony 6 support, it is functionally a breaking change shipped in a patch. Pin versions and validate before bundling it into a sprint commitment.
• Use cases it unblocks: any workstream that requires running on the current Laravel/PHP LTS line, including PHP 8.2/8.3 migrations where lingering utf8_encode calls surface as deprecation noise or, in stricter setups, as test and static-analysis failures.
• Roadmap signal, not roadmap item: nothing here changes user-facing behaviour. It does not justify reprioritising features; it justifies keeping the dependency current as routine hygiene.

When to Consider This Package

Consider adopting or retaining it when:

• You are on, or planning to move to, Laravel 11 / Symfony 7, and this release closes the compatibility gap.
• You want a dependency that clears PHP 8.2+ deprecations now, rather than carrying a runtime warning into a future PHP major.
• Your own codebase is clean of utf8_encode and you can consume the change without behavioural drift. If you depended on that function's lenient ISO-8859-1 conversion, verify output on non-UTF-8 input — removal is a behaviour change, however obscure the path.
• The package's core capability is still the cheapest option versus building in-house; continued maintenance is the main thing that erodes a build-vs-buy case, and this release argues against erosion.

Look elsewhere when:

• You are pinned to Symfony 6 / an older Laravel and cannot move. Confirm whether v6.0.1 is additive (both Symfony 6 and 7 supported) or a cut-over; if cut-over, stay on the prior 6.0.x line and track it as technical debt with a dated owner.
• The package has no stated support window, no CI matrix across PHP/Laravel versions, or this is the only release in a year. A single compatibility patch is a data point, not a maintenance guarantee.
• The only change you need is the deprecation fix, and a one-line local patch is cheaper than a dependency bump this cycle.
• Your threat model or compliance regime requires vendor support, SBOM disclosure, or a security policy — compatibility notes alone don't satisfy that.

How to Pitch It (Stakeholders)

For executives (one paragraph): A dependency we rely on has shipped a maintenance release that keeps it compatible with the current Laravel/Symfony line and removes a call to a PHP function that the language is phasing out. There is no new functionality and no user-visible change. The value is risk reduction: without this, our next framework upgrade would have required either a fork or a replacement project. It is a routine upgrade with a low cost of adoption.

For engineering leads: Patch release, semver-compatible on its face. Two things to verify before merge: (1) whether Symfony 7 support was added alongside Symfony 6 or replaced it — if replaced, it's a breaking change wearing a patch number and our version constraint must reflect that; (2) the removal of utf8_encode changes encoding behaviour on any ISO-8859-1 code path, so grep our own code for equivalent calls and confirm test coverage on non-UTF-8 input. Then bump, run the suite, and pin.

For the roadmap conversation: frame this as a dependency-health item with a fixed cost, not a feature. The decision it informs — stay on the current framework line or budget for a migration — is worth more than the upgrade itself, and answering it now is cheaper than answering it under deadline.