Service Annotation Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for DI boilerplate: This bundle exists to remove hand-written service definitions from Symfony-style DI config. The PM decision it informs is whether attribute/annotation-driven service registration is worth an external dependency versus explicit config or a small internal convention. For most teams the "buy" side wins only if you already live in Symfony's container semantics.
• Platform/upgrade roadmap: Release 1.1.6 adds Symfony 7 support. That is the signal that matters for planning — it means the package is still tracking the current Symfony major, so it is viable to keep in a stack that is moving to Symfony 7, and it removes a blocker from any Symfony 6→7 upgrade plan where this package was the holdout.
• Feature/DX roadmap input: If your team is designing internal bundle or module scaffolding, this package is a reference implementation for attribute-based service discovery. It can justify investing in "convention over configuration" tooling internally rather than pulling this in directly.
• Stack-fit decision (Laravel vs. Symfony): This is a Symfony bundle, not a Laravel package. It does not integrate with Laravel's service container, auto-discovery, or AppServiceProvider model. The PM-relevant conclusion is that it is generally not a fit for a pure Laravel application, and is relevant mainly for Laravel-adjacent codebases that embed Symfony components, maintain shared bundles, or are mid-migration between the two.
• Maintenance/lifecycle risk tracking: Maintenance releases like 1.1.6 are a low-cost signal for a periodic "is this dependency still alive and compatible" review rather than a feature trigger. No new capability, no deprecation, no migration work — so no roadmap slot should be consumed by this release.
• Vendor and bus-factor exposure: Small, single-maintainer-adjacent packages warrant an explicit decision on acceptable risk. This release does not change that posture; it confirms continued maintenance without reducing concentration risk.

When to Consider This Package

Consider it when:

• You are building or maintaining a Symfony application or reusable bundle and want to reduce manual service registration in YAML/XML/PHP config.
• You have a mixed or transitional codebase where Symfony DI conventions are already in play alongside Laravel, and you need consistency in the Symfony-side modules.
• You are on, or moving to, Symfony 7 — 1.1.6 explicitly removes that as a compatibility blocker.
• Your team is small and the DX gain from annotation/attribute-driven wiring is material relative to the cost of an extra dependency.
• You want a narrow, single-purpose dependency rather than a larger framework extension.

Look elsewhere when:

• The application is plain Laravel. Laravel's container, package auto-discovery, and ServiceProvider model already cover this ground; adding Symfony DI semantics buys complexity, not capability.
• You need long-term vendor support, SLAs, or a large contributor base. This is a small package with a correspondingly narrow support surface.
• You rely on static analysis, IDE navigation, and explicit wiring as a hard standard. Attribute-driven registration shifts service definitions away from greppable config, which is a real cost in larger teams.
• You are standardizing on PHP attributes only and want to drop the Doctrine-annotations-era pattern entirely; verify the package's attribute story against your coding standard before adopting.
• You need framework-agnostic DI rather than Symfony-specific behavior.

How to Pitch It (Stakeholders)

To executives: This is a small, low-risk maintenance update to a niche Symfony dependency — it adds support for the current Symfony major version. It is not a product feature and does not change what we ship. Its value is narrow but real: it keeps an upgrade path open and confirms the dependency is still maintained. No budget, headcount, or roadmap change is implied. The strategic point is that this package is only relevant if we are running Symfony-style service configuration; for our Laravel surface area it is out of scope, and we should treat adoption as an architecture decision rather than a feature decision.

To engineering: Version 1.1.6 is a compatibility bump — Symfony 7 is now allowed, with no breaking changes, no deprecations, and no API surface change. Practically, this unblocks keeping the package through a Symfony 6→7 upgrade and should be verified in CI against the Symfony 7 matrix. Before wider use, confirm two things: (1) whether we are on annotations or native PHP attributes, since that affects tooling and static analysis, and (2) that container cache warmup and service discovery behavior are covered by tests in our setup. For Laravel-only services, do not introduce this — use the framework's own container and providers. Recommended posture: track it, upgrade it opportunistically, and revisit adoption only if we introduce Symfony components or shared bundles.

Recommendation: Adopt only in Symfony-based or mixed-stack modules; treat 1.1.6 as a routine upgrade with no migration effort and no roadmap impact.