Dadata Bundle Laravel Package

Product Decisions This Supports

• Upgrade timing and platform roadmap: v1.6.0 adds Symfony 7 support, which is the compatibility line most modern Laravel releases sit on. This release is the signal that lets you schedule a Laravel/PHP 8.2+ upgrade without the package becoming the blocking dependency in the chain.
• Build vs. buy: This is an interoperability layer, not a product feature. The decision it informs is whether to maintain in-house glue code between Laravel and Symfony components (console, messenger, serializer, HTTP foundations) or consume a maintained package. A versioned release with a current-framework compatibility bump is evidence toward "buy/consume."
• Vendor health and risk register: A solo compatibility release tells you the maintainer is still responsive, but also that feature velocity is low. For a PM, that maps to a maintenance-risk rating, not a capability gain — budget for a fallback plan rather than counting on roadmap influence.
• Dependency floor decisions: Symfony 7 requires PHP 8.2+. Adopting this release implicitly raises your minimum PHP version. That is a real product constraint if you support self-hosted or on-prem deployments on older runtimes.
• Scope discipline: This release does not unlock new user-facing capability. Do not let it into a sprint as a "feature"; treat it as technical maintenance with an upgrade-path payoff.

When to Consider This Package

Consider it when:

• You run Laravel and already depend on Symfony components (directly or transitively) and want those contracts to stay version-aligned across framework upgrades.
• You are planning or currently executing a move to Symfony 7 / a Laravel release built on it, and need your dependency tree to resolve cleanly.
• You want a maintained bridge rather than owning custom adapter code with no upstream.
• Your deployment target is PHP 8.2 or newer, so the raised floor costs you nothing.

Look elsewhere or defer when:

• You are pinned to Symfony 6.4 LTS or an older PHP runtime for contractual or on-prem reasons — this release moves you forward, not backward, and there was no stated backward-compatibility commitment in the notes.
• Your stack is pure Laravel with no Symfony surface area; the package adds a dependency without buying you anything.
• You need feature velocity, SLAs, or vendor-backed support. Compatibility-only releases are a maintenance signal, not a support signal.
• You cannot verify the test matrix covers Symfony 7. Before adopting, check CI config, PHP version coverage, and whether the constraint was widened or the old major dropped — the release note is one line and does not say which.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost dependency update, not a new capability. Its value is optionality — it keeps our framework upgrade path open and avoids us writing and owning custom integration code. The cost is a PHP 8.2 minimum, which we should confirm against our deployment commitments before committing.

To engineering: v1.6.0 is a compatibility release adding Symfony 7 support. Verify three things before merging: whether Symfony 6 support was dropped (breaking for anyone still on 6.4), whether the PHP floor was raised to 8.2, and whether CI actually exercises Symfony 7 rather than just widening the composer constraint. Run a dependency resolution check against the target Laravel version and confirm no transitive conflicts. Then schedule it as routine maintenance alongside the framework upgrade — it should not be a standalone roadmap item.