Symfony Workerman Bundle Laravel Package

Product Decisions This Supports

• Runtime upgrade planning: The 0.0.7 release adds PHP 8.5 support, which directly unblocks teams planning to standardize on PHP 8.5 across the Laravel estate. This is the primary decision this release informs — whether the package can be part of a PHP 8.5 migration wave or must be pinned to an older runtime.
• Build vs. buy / adopt vs. fork: Compatibility with the current PHP line is a standard "keep vs. replace" signal. A package that tracks upstream PHP releases reduces the case for forking or replacing it with an in-house implementation.
• Version-pinning and upgrade sequencing: At 0.0.7 the package is pre-1.0. The release supports a decision to adopt it only in low-criticality paths, or to gate adoption behind a compatibility spike, until a 1.0 stability commitment appears.
• Roadmap timing for dependent features: Any internal feature that depends on this package can now be scheduled against a PHP 8.5 target rather than deferred. Product should confirm which roadmap items were previously blocked on runtime compatibility.
• Maintenance posture as a vendor signal: A compatibility-only patch at 0.x indicates active but narrow maintenance. This supports decisions about SLA expectations, support contracts, and whether to carry a local patch set.
• Not supported by this release: No new capabilities, no API changes, no deprecations. Do not use 0.0.7 as justification for new feature investment or for expanding the package's scope in the product.

When to Consider This Package

Adopt when:

• Your platform roadmap includes PHP 8.5 and you need dependencies that will not block that migration.
• The package is used in non-critical or well-isolated paths where a pre-1.0 API can be pinned and upgraded deliberately.
• You have a dependency policy that requires current-runtime support, and this release is the first version that satisfies it.
• You want a maintained upstream rather than an internal fork, and this release demonstrates the maintainer is tracking PHP releases.

Look elsewhere or defer when:

• You require a stable public API. The 0.x version line gives no compatibility guarantee; a 0.0.x patch is a compatibility claim, not a stability claim.
• You need documented support windows, security response commitments, or an LTS cadence — none of that is evidenced here.
• The package sits on a critical path and you cannot absorb an unannounced breaking change in a minor release.
• You are still on PHP 8.1–8.3 and have no near-term 8.5 plan; this release changes nothing for you, and adoption should wait for a functional reason.
• The only signal you have is this changelog. "Support 8.5" is a one-line note with no linked test matrix, CI evidence, or deprecation detail — verify against the repository before committing.

Due diligence before adoption: confirm PHP 8.5 is actually exercised in CI across supported Laravel versions, check whether the release drops any older PHP version, and read the diff rather than the changelog line.

How to Pitch It (Stakeholders)

For executives: A dependency we rely on has shipped a maintenance release adding PHP 8.5 compatibility. This is a small, low-risk change with one real benefit: it removes a potential blocker from our PHP 8.5 upgrade path and reduces the chance we have to replace or fork this package later. There is no new functionality and no cost implication. The caveat is that the package is still pre-1.0, so I recommend we keep it confined to non-critical surfaces and revisit once it reaches a stable release.

For engineering: Version 0.0.7 adds PHP 8.5 support. Treat it as a compatibility patch, not a feature release. Before we bump, confirm 8.5 is covered in the upstream test matrix and check whether older PHP versions were dropped. Pin the exact version, keep it off critical paths while we are on 0.x, and add a note to the PHP 8.5 migration epic that this dependency is no longer a blocker. If we need 8.5 support sooner than a 1.0 release arrives, this is our signal to start a local patch rather than wait.