Workingforumbundle Laravel Package

Product Decisions This Supports

• Roadmap: v6.0 is a compatibility and maintenance release, not a feature release. It does not unlock new product capability — it protects existing capability. Budget it as dependency hygiene in the current cycle, not as a roadmap bet, and do not let it consume roadmap credibility.
• Build vs buy: The headline change — removing reliance on the abandoned framework-extra-bundle — is exactly the unglamorous upstream upkeep that tells you the maintainers are still investing. That materially lowers the "we will end up forking this" risk and is a point in favor of staying on the package rather than replacing it.
• Upgrade gating: The major version bump plus raised minimum versions (markdown rendering, time rendering, Symfony constraints) makes our runtime floor a product constraint. Any roadmap item that assumes an older PHP/Symfony baseline needs re-validation before commitment.
• Migration scope: If any of our integration surface still uses annotation-era patterns, the conversion of Security attributes to isGranted and ParamConverter to ArgumentResolver is a scoped ticket, not a drop-in. Size it before we schedule the bump.
• User-visible surface: Rendered output — markdown formatting and date/time presentation — remains the part users actually see. The release moves minimums underneath that surface, so the renderer regression suite (formatting, relative dates, timezones) is the real acceptance test for this upgrade.
• Use cases supported: internal API reference, developer portal, and any docs/changelog surface where correctness of rendered markdown and timestamps matters more than new functionality.

When to Consider This Package

Adopt or upgrade when:

• You are already standardizing on modern Symfony components and attribute-based configuration — v6 moves with that current rather than against it.
• You want a maintained renderer for docs output instead of owning markdown and date formatting in-house.
• You can absorb a major-version upgrade cadence and value a visible maintenance signal over a stable-but-stale pin.

Look elsewhere or defer when:

• You are pinned to older Symfony or PHP versions. v6 raises the floor; backporting or holding a fork becomes your cost, not the maintainer's.
• You depend on legacy annotation-based security or param conversion in your integration. That is a migration with its own QA burden.
• You are Laravel-only and never touch the Symfony bridge. These changes are largely inert for you: low risk, but also low value — do not spend political capital selling it.
• You are shopping for new capabilities. This release delivers none, and there is no evidence of feature velocity to bet on yet.

How to Pitch It (Stakeholders)

Executives: v6.0 is housekeeping, not headroom. The maintainers removed a dependency on an abandoned upstream component and raised version floors — a durability signal, not a feature. The cost is one upgrade cycle; the benefit is staying on a supported path instead of drifting toward an eventual forced migration.

Engineering: Expect a major bump with real migration work only where annotation-era patterns are in use — Security attributes become isGranted, ParamConverter becomes ArgumentResolver. Grep for those before scheduling; if our Laravel-facing surface does not touch the Symfony bridge, treat this as a routine dependency bump with near-zero impact. The raised minimums for markdown and time-rendering libraries are the likeliest source of visible breakage, so run the renderer regression suite — formatting, relative dates, timezone handling — as the gate.

Recommendation: Upgrade on normal cadence; do not fast-track. There is no feature narrative to sell and no signal yet of new capability. Revisit the assessment if a v6.x minor introduces functional changes.