Upgrading
Symfony / PHP minimums, BC policy, and the v4.3 cache-flush note. Everything you need to track the upstream library bumps without breaking your app.
The bundle versions in lockstep with opcua-client and
opcua-session-manager. A v4.3.x bundle uses ^4.3.x of both
upstream packages.
Composer constraint
In your project's composer.json:
"php-opcua/symfony-opcua": "^4.3"Caret allows minor/patch updates within the 4.x train. Major bumps (4 → 5) signal an intentional breaking change.
Reading the CHANGELOG
Three files matter for an upgrade:
| File | Read for |
|---|---|
symfony-opcua/CHANGELOG.md |
Bundle-side changes (config keys, services, commands) |
opcua-client/CHANGELOG.md |
Wire protocol, modules, builder API |
opcua-session-manager/CHANGELOG.md |
Daemon features and security |
A bundle entry references both upstream entries with the "downstream impact" callouts, so reading just the bundle one usually suffices.
Symfony version matrix
| Bundle version | Symfony support (per composer.json) |
|---|---|
^4.1, ^4.2 |
6.4 LTS, 7.x |
^4.3 (current) |
7.3+ or 8.x (^7.3|^8.0) |
Note: ^4.3 raised the Symfony floor — Symfony 6.4 LTS is not
supported on the current release. Stay on ^4.2 if you need 6.4
LTS compatibility.
PHP 8.2 is the minimum across the entire 4.x line. PHP 8.3 / 8.4 work transparently.
v4.2 → v4.3 — what to do
For most apps: two steps.
1. Bump and update
composer require php-opcua/symfony-opcua:^4.3
php bin/console cache:clearThe cache clear is for Symfony's container cache; nothing OPC UA-specific yet.
2. Flush the persistent cache pool
The OPC UA wire-cache codec was hardened — unserialize() is
out, JSON behind an allowlist is in. Pre-v4.3 cached entries
are discarded on first access.
If you use a Redis / database / file pool for the bundle's cache, flush it explicitly to avoid a brief cold-cache window:
php bin/console cache:pool:clear cache.appOr your specific pool name (cache.system, cache.redis, etc.).
That's the whole upgrade. Everything else (NodeManagement in
defaults, ServiceFault decoding, daemon socket-permission fix,
…) is transparent.
Symfony Flex recipe drift
If you forked the project's Flex recipe, compare against the current recipe shape:
composer recipes:install php-opcua/symfony-opcua --reset--reset overwrites the recipe-managed files; review the diff
before committing.
Removing deprecated config keys
The bundle has been additive-only through the 4.x train —
no config keys have been removed. Your existing
config/packages/php_opcua_symfony_opcua.yaml works unchanged
on each new minor.
If a future major (5.x) does deprecate keys, the corresponding
entry in symfony-opcua/CHANGELOG.md will spell out the
migration path.
After upgrade
A short sanity check:
php bin/console debug:config php_opcua_symfony_opcua | head -40
php bin/console debug:autowiring opcua
php bin/console opcua:session --helpAll three should succeed. If the third one fails, the bundle's
console command isn't registered — most often a stale
var/cache/ (run cache:clear).
Long-running workers — restart
After the upgrade, restart any long-running workers:
sudo systemctl restart opcua-session-manager
sudo systemctl reload-or-restart 'messenger@*'Workers cache the autoload index at boot. Without a restart they keep running the pre-upgrade code until the next deploy.
What "supported" means
The bundle's CI matrix runs against:
- PHP 8.2, 8.3, 8.4, 8.5 (release candidates)
- Symfony 7.3, 7.x current, 8.x current
- Ubuntu, macOS, Windows
A version combination outside this matrix may work but isn't guaranteed. File issues at github.com/php-opcua/symfony-opcua/issues.
Where to read next
- Bundle YAML — the full config tree.
- Caching — the v4.3 cache-codec details.