Influxdb Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy: v4.0.0 is a maintenance-health signal. Dropping PHP 7.x and Symfony 4.4/5.0–5.3 while adding Symfony 6 support indicates an actively maintained package tracking the modern ecosystem — this lowers the "abandoned dependency" risk that usually pushes teams toward building in-house. Leans buy/adopt.
• Roadmap sequencing (platform upgrades): The PHP 8 floor is a hard breaking change. If any service is still on PHP 7.4, adopting v4 forces that service's PHP upgrade, and possibly its Laravel/Symfony upgrade, into the same release train. Treat this as a dependency that gates — and therefore schedules — your platform modernization work.
• Framework-version readiness: Symfony 6 support is the forward-compatibility enabler for newer Laravel majors. Adopting v4 now reduces the risk of being blocked mid-upgrade later, when the alternative becomes "patch the package ourselves."
• Support matrix / deprecation policy: Dropping three Symfony minor ranges is a deliberate narrowing of supported combinations. This informs the support policy we publish to internal consumers and the version-pinning guidance in our dependency standards.
• Use cases: Best suited to applications on PHP 8+ with Symfony components at 5.4 or 6.x — i.e., anything reasonably current. Least suited to legacy estates mid-migration or long-term-support branches that cannot move off PHP 7.4.

When to Consider This Package

Adopt when:

• Your runtime is PHP 8.0+ and your Symfony components are 5.4 or 6.x — the new floor matches your stack, so v4 costs nothing extra.
• You are planning a Laravel/PHP upgrade in the next 1–2 release cycles; taking v4 now piggybacks on work you were already doing.
• Ongoing maintenance of the dependency matters — the release cadence suggests the maintainer is responsive to ecosystem shifts, which is a reasonable proxy for future security patching.

Look elsewhere or defer when:

• You are pinned to PHP 7.4 or Symfony 4.4 / 5.0–5.3. Staying on the prior major is viable short-term, but you inherit a dependency that will diverge from the ecosystem — budget for the migration rather than assuming it away.
• You need a guaranteed long support window on legacy PHP; a package that has just dropped it is unlikely to reverse course.
• The package is load-bearing but thinly maintained — a major version bump that is purely a support-matrix change is cheap to absorb, but confirm it isn't the last release before abandonment.

Caveat: the release notes describe only compatibility floors. They contain no functional changes, new capabilities, or deprecations — so the decision here is entirely about upgrade cost and maintenance confidence, not about new user-facing value.

How to Pitch It (Stakeholders)

For executives: This is a routine dependency modernization, not a feature release. The package now requires PHP 8 and Symfony 5.4+, and supports Symfony 6. The practical effect: it keeps us aligned with a supported, actively maintained component and removes a future blocker from our platform upgrade path. The cost is bounded — it is only "breaking" for services still on PHP 7.4, which we should be retiring anyway.

For engineering: v4.0.0 changes the support matrix only — no new APIs, no behavior changes, no deprecations. Two things to action: (1) inventory any service on PHP <8 or Symfony <5.4 before bumping, since those will fail to resolve; (2) pin the prior major for those services and schedule their upgrade explicitly rather than letting the constraint surface as a broken build. For everything on a current stack, this should be a low-risk composer update with a regression pass, not a rewrite.

Recommendation: adopt on current-stack services now; treat legacy services as a tracked, dated migration item rather than a blocker to the upgrade.