Ad Poller Bundle Laravel Package

Technical Evaluation

Architecture fit. The package is consumed as a Composer dependency inside a Laravel application; this release does not change runtime architecture, service-provider wiring, or configuration surface. What changes is the underlying vendor lineage: zendframework/* packages are end-of-life (Zend Framework reached EOL in December 2019), and laminas/* is the Linux Foundation–backed continuation of the same codebase. Moving requirements to Laminas aligns the package with the maintained upstream, which is the correct long-term posture for anything we intend to keep in a production dependency tree.

Integration feasibility. Mechanically this is a composer.json requirement swap plus the corresponding namespace migration (Zend\* → Laminas\*). It is feasible in a normal Laravel app, but feasibility is decided by the consumer's dependency graph, not by this package. If any other dependency in our tree still pins zendframework/*, Composer will either fail to resolve or install both lineages side by side, which is the worst outcome: duplicated code, divergent patch levels, and confusing autoload behaviour.

Technical risk. The release is published as 1.1.0 — a minor bump — but the underlying change has breaking potential that semver does not capture:

• Leaked types. If the package's public API (method signatures, return types, thrown exceptions, DTOs, config value objects) references Zend\* classes, any consumer that type-hints against them, catches those exceptions, or implements those interfaces will break at runtime with "class not found" rather than at install time.
• Transitive removal. Dropping zendframework/* from this package's requirements can silently remove a package that our code depended on incidentally — a classic "worked because someone else required it" failure.
• Serialized state. Queued jobs, cached objects, and signed payloads that serialize instances of these classes will fail to unserialize if the class name changed. This is a production incident, not a test failure.
• Verification gap. A one-line changelog gives no signal on whether both lineages are supported, whether tests run against both, or whether the PHP version floor moved.

Key questions for the maintainer.

1. Is this a hard switch to Laminas, or does the package support both zendframework/* and laminas/* via Composer's provide/replace or conditional requirements?
2. Does any part of the public API expose Zend\* or Laminas\* types? If yes, this is a major-version change mislabelled as minor.
3. Which specific packages were swapped, and were any dropped entirely rather than renamed?
4. Did the PHP version constraint or Laravel version constraint change in the same release?
5. Is there a test matrix covering the supported PHP/Laravel combinations post-swap?
6. Is 1.0.x still receiving security patches during a transition window?

Integration Approach

Stack fit. Standard Laravel consumption path: composer require, package auto-discovery for the service provider, optional facade and config publish. No infrastructure, queue backend, or hosting change is implied by this release. The real fit question is horizontal: how many other packages in our tree sit on the Zend/Laminas boundary.

Migration path.

1. Inventory first. Run composer why zendframework/* and composer why laminas/* on every application that depends on this package. Anything still requiring the Zend lineage is a coordination problem to solve before upgrading, not after.
2. Pin or upgrade, deliberately. Applications that cannot yet move should stay on the 1.0.x line. Do not let a minor-version bump ride along inside an unrelated feature branch — this change deserves its own PR and its own rollback point.
3. Upgrade on a branch with a committed composer.lock diff that a reviewer actually reads. The lock diff is the primary evidence of what landed in the tree.
4. Sweep for leaked namespaces. Grep the application for Zend\ — in use statements, catch blocks, config files, and class-string references in app/config — and run static analysis (PHPStan/Psalm at the level the project already uses) against the upgraded tree.
5. Drain volatile state before deploy. Flush caches that may hold serialized instances and ensure queues are drained or that in-flight jobs are compatible, so nothing attempts to unserialize a class that no longer exists.
6. Exercise the unhappy paths, not just the happy path: exception handling around package calls, console commands, scheduled tasks, and any custom extensions of package classes.

Compatibility. Treat 1.1.0 as potentially breaking regardless of the version number. Confirm the package's PHP floor against our runtime, and confirm Laravel framework compatibility is unchanged. Where the package is a transitive dependency rather than a direct one, verify the parent still allows 1.1.0 in its constraint range — otherwise we upgrade nothing and merely believe we did.

Sequencing. Dependency inventory → constraint reconciliation across the fleet → upgrade in a non-production environment → full test suite plus targeted serialization and exception-path checks → staged rollout with one low-traffic service first → fleet-wide. Budget the inventory step as the long pole; the composer update itself is minutes.

Operational Impact

Maintenance. This is a net positive and the strongest argument for the release. Laminas receives active security maintenance; Zend Framework does not. Staying on the Zend lineage is an accumulating liability with a known end state, and every quarter we defer makes the eventual move larger because more of our own code will have grown against the deprecated namespaces.

Support. Upstream documentation, issue trackers, and community answers increasingly assume Laminas. Internal runbooks, onboarding material, and any in-house extensions that reference Zend by name need a documentation pass. Vendor support for the Zend lineage is effectively "community memory," which is a real support risk if we hit an edge case.

Scaling. No expected runtime performance change — Laminas is a continuation of the same code, not a rewrite. No meaningful effect on throughput, memory, or horizontal scaling. The scaling concern here is organisational rather than technical: the number of services that must be coordinated grows with fleet size, and each one carries its own dependency graph.

Failure modes to watch.

• Fatal at autoload, not at deploy. Class "Zend\..." not found surfaces on the first request that touches the affected path, which may be a rarely exercised branch. This is why static analysis and a grep sweep matter more than happy-path smoke tests.
• Composer resolution deadlock in CI when a sibling dependency still pins Zend — usually presenting as a confusing constraint error rather than a clean failure.
• Silent dual lineage: both Zend and Laminas installed, autoload order deciding which class wins. Passes tests, fails unpredictably in production. Reject any lock file containing both.
• Poisoned queue or cache payloads after deploy, producing unserialize failures on workers.
• Third-party plugins that extend the package and were compiled against Zend types, breaking without warning.

Ramp-up. Low for engineers. Laminas is API-compatible with Zend in all but namespace, so existing familiarity transfers directly; the learning curve is essentially "find and replace, then verify." Expect roughly a day of dependency triage and testing per application, dominated by the inventory and verification steps rather than by the change itself. The one group that needs more than a day is whoever owns cross-service dependency coordination — that work is political and scheduling-bound, not technical.