Common Bundle Laravel Package

Product Decisions This Supports

• Feature scoping and build-vs-buy: This package is a candidate whenever we need annotation-driven metadata inside a Laravel/PHP application (declarative config, scanned class metadata, convention-over-configuration wiring). A buy/adopt decision here removes a small but real chunk of custom reflection/parsing code from our backlog.
• Upgrade and maintenance planning: Release 1.2.0 removes ZanAnnotation as a backward-compatible break. That is a direct input to roadmap sequencing — any feature we build on top of the annotation surface needs a pinning and migration plan before we commit.
• Dependency risk budgeting: A public class removed in a minor version (1.2.0) is a semver-discipline signal. PM-level takeaway: treat this dependency as fast-moving and budget for periodic upgrade work rather than assuming a stable API.
• Use-case validation: Justifies a short discovery task — inventory whether anything in our codebase (or planned feature) touches ZanAnnotation. Outcome determines whether the annotation layer is a viable foundation or a liability.

When to Consider This Package

Consider adopting when:

• We are on Laravel/PHP and want annotation-style metadata without writing our own scanner.
• Our usage is confined to surface area we can wrap behind an internal adapter, so future removals are absorbed in one place.
• We can pin to an exact version and have a named owner for upgrade reviews.

Look elsewhere (or defer) when:

• We currently use ZanAnnotation. It is gone in 1.2.0 — no deprecation path is documented in these notes. Pin to 1.1.x and migrate, or do not adopt.
• We need a long-term-stable, LTS-style contract; frequent BC breaks in minor releases conflict with that.
• Native PHP 8 attributes cover the use case — prefer the platform primitive over a third-party annotation layer.
• The annotation mechanism sits on a critical path (routing, auth, validation) where a surprise removal becomes an outage.

Immediate action: audit for ZanAnnotation references, hold upgrades to 1.2.0 until that audit clears, and record the removal in our dependency changelog.

How to Pitch It (Stakeholders)

For executives: We evaluated a Laravel/PHP package that provides annotation-based configuration. It could save us writing and maintaining custom parsing code. However, the new 1.2.0 release removes a public class (ZanAnnotation) with no deprecation path and no major-version bump, which tells us the maintainer's compatibility guarantees are weak. Recommendation: don't standardize on it for anything customer-facing; if we use it at all, isolate it behind our own interface so a future removal costs us an afternoon rather than a release.

For engineering: 1.2.0 is a breaking change. Before upgrading, grep for ZanAnnotation; if it appears, stay on 1.1.x and file a migration ticket. Regardless of outcome, wrap the package's annotation API in an internal adapter, pin the version explicitly, and add a release-watch task. Note the semver concern — a class removal in a patch/minor line means we should assume further breaks and design accordingly.

Confidence note: This assessment is based on a single release note and no prior evaluation data; the package's overall fit, maintenance health, and test coverage are still unverified. Recommend a time-boxed spike before any adoption decision.