Ad Poller Laravel Package

Product Decisions This Supports

• Build vs. buy / wrap vs. write: The 0.2.0 change (replacing zendframework/* requirements with laminas/* in composer.json) signals this package is an integration layer over the Zend→Laminas component family rather than original business logic. That makes the build-vs-buy math concrete: if the wrapped surface is small and stable, a thin internal adapter may be cheaper to own than a 0.x third-party dependency; if the wrapper carries real glue code (Laravel service provider bindings, config, facades), buying is usually the better trade.
• Dependency-lifecycle roadmap: Zend Framework reached end-of-life and was relicensed/continued as Laminas. A package still pinning zendframework/* is inheriting abandoned upstreams; 0.2.0 removes that liability. This is a hygiene release, not a feature release — it moves the package from "unmaintained transitive risk" to "maintained upstream," which directly affects your security-patch SLA and PHP-version upgrade path.
• Upgrade scheduling: Because the change is in composer.json requirements, the blast radius is dependency resolution, not application code. It is cheap to adopt on greenfield work and potentially disruptive on an existing lockfile that still resolves zendframework/* elsewhere. This informs whether you slot the bump into routine maintenance or treat it as a scoped migration ticket.
• Pre-1.0 risk posture: Version 0.2.0 is the second minor release of a 0.x package. SemVer permits breaking changes on minor bumps, and the project has already demonstrated a hard dependency swap on one. Treat the public surface as unstable and budget for re-validation on each release.
• Use-case fit: Worth evaluating where you specifically need the Laravel-friendly binding this package provides around the Laminas component — configuration publishing, container bindings, artisan/console integration, or framework-native validation/filtering — rather than using the raw Laminas library directly.

When to Consider This Package

Consider adopting when:

• You are on a supported Laravel version and want framework-native bindings around a Laminas component instead of hand-wiring a service provider.
• Dependency hygiene matters to your team (security review, SBOM, or an internal policy against EOL packages) — 0.2.0's move to laminas/* is exactly the remediation such a policy requires.
• The integration glue is genuinely non-trivial; a well-maintained wrapper saves more than it costs.
• You can absorb pre-1.0 churn: pin an exact version, review changelogs on every bump, and have tests covering the integration boundary.

Look elsewhere when:

• You need LTS or contractual support. A 0.x community package with a single-maintainer profile is not a support vehicle.
• You can use Laminas directly. If your usage is one or two classes, a first-party service provider in your own codebase removes an entire supply-chain hop.
• The package's only differentiator is the zendframework→laminas shim. That is a maintenance fix, not a capability; verify there is real Laravel-specific value beyond it.
• You are already deep in zendframework/* elsewhere. Mixing both families in one lockfile invites duplicate-class and autoload conflicts; consolidate first.
• Your platform is pinned to old PHP or Laravel. Confirm the supported matrix before committing — the release notes do not state it.

Due diligence before adoption:

1. Read the 0.2.0 diff, not just the changelog. Confirm no zendframework/* requirements remain, including in dev dependencies and suggested packages.
2. Run composer why zendframework/zendframework and equivalent audits on your tree to catch transitively-still-Zend packages — the switch only helps if nothing else reintroduces the old family.
3. Check release cadence, open-issue responsiveness, test coverage, and whether CI runs the Laravel and PHP versions you actually deploy.
4. Verify namespace and class-name changes are handled — Zend→Laminas renamed namespaces (Zend\* → Laminas\*), so any code or config referencing the old FQCNs will break.
5. Confirm a rollback path: keep the prior constraint available in case of resolution conflicts.

How to Pitch It (Stakeholders)

For executives — one paragraph: This release is a maintenance fix that swaps an end-of-life dependency family (Zend Framework, now discontinued) for its actively maintained successor, Laminas. It adds no new features and changes no product surface, but it materially reduces supply-chain and security risk: abandoned upstream packages stop receiving patches, and continuing to depend on them is a finding in most security reviews. The cost to adopt is low — a dependency bump plus regression testing — and the cost to defer is a growing audit exception. Recommend adopting in the next maintenance window if we use this package, and treating it as a blocking prerequisite if we are evaluating it now.

For engineering leads — the technical brief: composer.json moves from zendframework/* to laminas/*. Expect namespace changes from Zend\ to Laminas\ in any published config, facade accessors, or documented FQCNs; grep the codebase and any cached config before deploying. Audit the full dependency tree for residual Zend packages that would reintroduce the old family and cause duplicate-class conflicts. Re-run the test suite against the app's real Laravel and PHP versions, since the release notes do not state a supported-version matrix. Pin the version — this is a 0.x package that has already made one breaking dependency change on a minor bump, so treat the API as unstable and gate future upgrades behind changelog review.

Bottom line: A small, unglamorous, risk-reducing release. No product decision changes hands — but it clears a dependency-hygiene objection that would otherwise block adoption, and it is the kind of maintenance signal worth weighing when judging whether to build on this package or wrap it ourselves.