Cacofony Laravel Package

Product Decisions This Supports

• Platform/support-matrix decision: 6.0.0 is a Symfony 6-only line. This forces a decision on which framework versions we officially support, and whether the product roadmap's minimum PHP/framework baseline moves in lockstep with it. If any part of the estate is still on Symfony 5.x, we now need a two-track support plan rather than a single dependency version.
• Upgrade cost vs. value trade-off (build vs. buy): the release is almost entirely a maintenance release — value is "stays supported, stays aligned with Symfony 6," not new capability. The PM decision is therefore a cost decision: budget the annotation→attribute migration work, or pin to the 5.x line and accept a growing security/support tail. This is a classic "pay now or pay more later" call, and it should be scheduled explicitly rather than inherited by default.
• Scope reduction we can bank: three features are removed — param fetcher, single-method routes, and the Conflict/Locked HTTP exception classes (now native to Symfony). Each removal is a chance to delete our own usage and shrink the code we own. Conversely, if we depend on any of them, that dependency is now a hard blocker and must be surfaced in the backlog immediately.
• Deprecation-driven roadmap input: annotations becoming attributes is an ecosystem-wide direction, not a package quirk. That justifies funding a codebase-wide annotation-to-attribute sweep as a standalone initiative with its own value (static analysis, IDE support, no docblock-based runtime magic), independent of this upgrade.
• Dependency-footprint decisions: with the exception classes absorbed into Symfony core, we can decide to stop treating this package as the source of truth for HTTP error semantics. Every capability that migrates upstream is a candidate for removing our own wrapper code — a small but real reduction in long-term ownership cost.
• Use-case validation: RestrictToRole and TemplateParameter are the surviving, still-useful surface. If our product does not actually use them, this dependency is not earning its keep and should be reconsidered at the next architecture review.

When to Consider This Package

Adopt (or upgrade to 6.0.0) when:

• The application is on Symfony 6 and PHP 8+, and the team has already moved — or is willing to move — route/controller configuration from annotations to PHP attributes.
• You actively use RestrictToRole (declarative access control at the controller layer) and/or TemplateParameter (passing controller data into templates without boilerplate). These are the two features that survived and represent the package's remaining reason to exist.
• You want role-based route restriction expressed as attributes colocated with the controller action, rather than in a separate security config — a genuine readability and reviewability win.
• You are comfortable with a breaking upgrade path and can absorb a coordinated, code-touching migration rather than a drop-in version bump.

Look elsewhere — or defer — when:

• You are on Laravel. This release makes the package's Symfony lineage explicit (Symfony 6 compatibility, Symfony-native replacements for removed classes). It is not a Laravel-ecosystem package, and no Laravel-specific value is delivered here. If the brief was "a Laravel package," that premise should be corrected before any adoption decision.
• You are on Symfony 5.x or earlier and cannot move. 6.0.0 offers you nothing; stay on the prior line and plan the framework upgrade as the gating item.
• You rely on param fetcher, single-method routes, or the package's Conflict/Locked HTTP exceptions. All three are gone. Migrate off them first, or you cannot take this release at all.
• You have heavy annotation-based configuration and no appetite for an attribute migration this cycle. The cost is real and lands on every controller touched.
• Your use case is thin — you need only role restriction, or only template parameters. Symfony's own security and controller facilities may cover it without a third-party dependency; evaluate that before renewing the commitment.
• You require a long-term-support guarantee or a predictable, non-breaking upgrade cadence. A release that flips configuration style and deletes three features in one major version signals a package that will keep making you pay attention.

How to Pitch It (Stakeholders)

To executives: this is a maintenance release — it keeps a dependency supported and aligned with Symfony 6, and it retires three features that Symfony now provides natively. There is no new customer-facing capability and no new revenue lever. The relevant number is the upgrade cost: an engineering effort to migrate controller configuration from annotations to attributes and to remove reliance on three deleted features. Approving it protects us from running an unsupported dependency; deferring it is a legitimate option only if we accept a defined end-of-support risk and put a date on the migration. The decision we want from you is a scheduling one, not a strategic one.

To engineering: treat this as a code-touching migration, not a version bump. Three things to plan: (1) convert RestrictToRole and TemplateParameter usage from annotations to attributes — that is the bulk of the work and it scales with the number of annotated controllers; (2) audit for and remove any use of param fetcher, single-method routes, and the package's Conflict/Locked exception classes, replacing the exceptions with Symfony's native equivalents; (3) confirm the Symfony 6 baseline holds across all environments and CI before merging. The upside is a smaller dependency surface, better static analysis and IDE support on attribute-based configuration, and one fewer place where our HTTP error semantics are defined. Recommend we scope the annotation audit first — that gives us a real effort estimate before we commit a date.