Influxdb Bundle Laravel Package

Getting Started

v4.0.0 is a platform/compatibility major: it drops PHP 7.x, raises the Symfony floor to 5.4, and opens the door to Symfony 6. There are no documented feature or API additions here, so treat this release as an environment upgrade rather than something to learn.

Start here, in order:

1. composer.json of the package — confirm the new constraints (php: ^8.0, symfony/*: ^5.4|^6.0) and check whether your app's other Symfony-adjacent dependencies (console, process, http-foundation, translation, var-dumper, mailer, mime, routing) can satisfy the same range.
2. The changelog/upgrade guide — release notes only list constraints. A major bump with an empty feature list usually still carries internal refactors: removed deprecated method calls, typed properties, return types, and possibly dropped constructor arguments. Diff src/ against the tag you're on before assuming nothing changed.
3. The service provider and config file — run php artisan vendor:publish in a scratch branch and diff the published config against your committed copy; config keys that gained/lost env() fallbacks are the most common silent breakage in a major.
4. Any facades, contracts, or events the package exposes — these are the surfaces your code actually touches.

First use case: upgrade one low-risk application (or a throwaway branch) to PHP 8.1+ and Symfony 5.4/6, pull v4, and exercise the package's primary path end-to-end before touching anything else. That tells you in an hour whether the major is a no-op for you or whether the undocumented internals moved.

If you are still on PHP 7.4, this release is your forcing function: you cannot take v4 until the runtime moves, and you should not stay on v3 indefinitely once the maintainers' CI is only running PHP 8.

Implementation Patterns

Two-stage upgrade, not one composer update. Upgrade the runtime and Symfony first, keep the package on the old major, deploy, verify. Then bump the package. Mixing both into a single lockfile diff makes it impossible to attribute a regression.

Pin Symfony in the root composer.json while you migrate. Adding an explicit symfony/console, symfony/process, etc. constraint at the version your app is actually tested on prevents Composer from opportunistically resolving to Symfony 6 on a transitive pass and gives you a deliberate, reviewable upgrade step later.

Constrain by platform, not by hope. Use config.platform.php in composer.json (or a CI matrix) so the lockfile you commit matches the runtime your images use. This matters more at a major boundary than at any other time.

Keep the package behind your own boundary. Where you already wrap it in a small service class, an interface binding in a service provider, or a queued job, this upgrade is a composer.json change plus a test run. Where package calls are scattered across controllers and Blade templates, every major becomes a search-and-replace exercise. If you are doing this migration and the calls are scattered, wrap them as part of the work.

Test the integration points, not just the unit. If the package touches HTTP, mail, queues, or the filesystem, add or keep feature tests that exercise the real facade through the container. Internals changed in a major are precisely what unit tests with mocks won't catch.

Budget for the CI matrix. If you maintain a package or a monorepo that depends on this one, add PHP 8.0/8.1/8.2 and both Symfony 5.4 and 6.x to your matrix so the widened constraint is actually verified rather than assumed.

Gotchas and Tips

• The release notes are understated. "Minimum PHP 8 / Symfony 5.4 / allow Symfony 6" describes the constraint diff, not the code diff. Do not read the absence of listed breaking changes as the absence of breaking changes — major version numbers are the signal, and the diff is the evidence.
• Symfony 6 is allowed, not required — and not necessarily tested by you. The maintainers' constraint says "compatible"; your app's combination of Laravel version, other packages, and Symfony 6 minor is a distinct proposition. Verify, then pin.
• Dependency-resolution deadlock is the most likely failure mode. Another package pinned to symfony/* ^4.4|^5.0 will block the upgrade with a wall of Composer output. Read the conflict block bottom-up: the last package named is usually the real blocker. composer why-not symfony/console 6.0 is faster than reading the prose.
• composer update vs composer update --with-all-dependencies. For a package you're bumping directly, composer update vendor/package -W is what actually lets shared Symfony deps move. Without -W you'll get a lock that satisfies nothing.
• PHP 8 deprecations surface as notices, not errors. Dynamic properties (deprecated in 8.2), passing null to non-nullable internal parameters, and implicit float-to-int conversions will show up in logs before they show up in tests. Watch storage/logs/laravel.log on a staging deploy.
• Check whether Symfony 6 forces a Laravel-side change. Laravel's own Symfony constraints vary by Laravel version; an old Laravel on Symfony 6 is a combination that may install but isn't a supported path. Match the Laravel version to the Symfony version before blaming the package.
• Re-publish and diff configs, don't overwrite them. Use vendor:publish --tag=... into a temp path and diff. Losing a hand-edited config key on a major upgrade is a classic self-inflicted outage.
• Extension points to audit: published config, bound contracts in the container, facade accessors, and any events the package dispatches. A renamed event or a changed event payload is invisible to static analysis and breaks listeners silently.
• Keep v3 viable during the transition. If you cannot move the runtime immediately, pin the old major explicitly ("vendor/package": "^3.0") so a routine composer update doesn't drag you across a major you haven't tested.
• Security posture: dropping PHP 7 and Symfony <5.4 means the maintainers are no longer obligated to patch unsupported branches. Staying on v3 past the next security advisory is the real cost of deferring this upgrade.