Ncr Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. wire-up (platform layer): This bundle is almost pure integration glue — it registers gdbots/ncr services into the Symfony container and exposes a config tree. The decision it informs is not "should we adopt NCR" but "do we spend engineering days writing our own service-provider glue or consume a maintained one." That remains a low-stakes, reversible call worth delegating to the tech lead.
• Platform-version coupling (new, and now the dominant decision): v5.0.0 is a hard breaking change — it requires Symfony 8.x and PHP 8.5+, with no fallback range. Adopting v5 effectively votes your roadmap onto the newest PHP minor and Symfony major simultaneously. This is no longer a "glue or hand-roll" conversation; it is a platform upgrade timeline conversation that touches hosting, CI images, static analysis, and every other dependency in the service.
• Pin-vs-follow decision: Because the floor jumped a full major on both PHP and Symfony, teams not ready to move must consciously pin to the previous 4.x line and accept a diverging fork. Make that a recorded decision with an owner and a revisit date, not a silent composer.json artifact.
• Vendor and bus-factor risk register: 0 stars, 0 dependents, single-vendor authorship — and now a demonstrated willingness to raise the platform floor to whatever the vendor's own stack runs. This is the package's most important product signal: the release cadence tracks the author's environment, not consumer adoption. Maintain a standing risk item (fork-and-own plan, pinning policy, upgrade cadence).
• Ecosystem standardization: If any part of the roadmap already sits on the gdbots stack (PBJ/PBJX-style message tooling, event/message-driven services), adoption commits the roadmap to Symfony and gdbots conventions at once. Use it to force the "are we a gdbots shop or not?" conversation once, rather than per-feature.
• Roadmap scope / time-to-first-commit: The bundle still removes boilerplate from the critical path of new Symfony services — a schedule lever worth pricing into delivery plans as a days-saved credit. But the credit is now partly offset by a mandatory runtime upgrade, which is a schedule cost on any service not already on PHP 8.5 / Symfony 8.
• Infrastructure readiness as a gate: PHP 8.5 is very new; base images, managed runtimes, and enterprise distro support lag by design. The bundle's floor is now a hosting and CI feasibility question that belongs in the same intake checklist as the architecture review.
• Use-case gating: Supports internal, Symfony-native, message/event-oriented services on current-generation runtimes. Does not support anything on older Symfony/PHP, broad OSS distribution, third-party extensibility, or non-Symfony runtimes.
• Upgrade and support-cost modeling: Apache-2.0 and actively maintained, but with no downstream users there is no community-tested upgrade path — and v5 proves the point. Budget internal ownership of breaking changes (including "we chose not to take this one") as a recurring line item.

When to Consider This Package

Adopt v5 when:

• You are already on, or are independently scheduled onto, Symfony 8.x and PHP 8.5+. The bundle is now only viable as a rider on a platform upgrade you were going to do anyway; it should never be the reason you do one.
• You have committed to, or are seriously evaluating, the gdbots NCR library. The bundle's entire value remains proportional to that dependency — standalone it is ~nothing.
• You want the fastest path to working container wiring for NCR services and have someone who can read the bundle source in an afternoon.
• You are comfortable treating it as vendored/forkable glue: internal ownership, pinned versions, a named maintainer, and a willingness to patch or fork if upstream stalls or jumps the platform again.
• You need a canonical reference for how the vendor intends NCR to be configured, even if you later replace the bundle with your own provider.

Pin to 4.x (don't take v5) when:

• Your services are on Symfony 6/7 or PHP 8.1–8.4 and the platform upgrade is not funded on this cycle. Take the pin, document it, and set a review trigger — but do not let "pinned forever" become the default state.
• Your build, deploy, or managed-runtime providers do not yet offer PHP 8.5. Verify this before the spike, not during delivery.

Look elsewhere when:

• You are not on Symfony — there is no fallback here, it is Symfony-specific by construction.
• You are not using NCR. Do not adopt "for later"; it delivers no capability on its own.
• You need community support, Stack Overflow answers, validated security advisories, or an ecosystem of examples. Zero stars and zero dependents means zero safety net — you are the first person to hit every edge case, including this version bump.
• Your team lacks gdbots domain knowledge and has no appetite to acquire it. The learning cost is in the ecosystem, not the bundle.
• Your service is customer-facing-critical with hard SLAs on a near-term horizon. A launch-blocking dependency that unilaterally raises its runtime floor is a poor bet for that surface.
• You cannot fork. If you'd be the sole consumer of a bug you find, you need the option to own the fix.

Practical gate (updated): require a time-boxed spike (1–2 days) that stands up a throwaway Symfony 8 / PHP 8.5 app, confirms your CI images and hosting support that runtime, and documents exactly which services and config keys the bundle registers — before any production commitment.

How to Pitch It (Stakeholders)

To executives (one line): "A small, free, Apache-2.0 Symfony integration layer for one of our backend libraries. Its new major version requires Symfony 8 and PHP 8.5, so it now moves in lockstep with the newest platform releases — we're treating it as code we own and only adopting it alongside a platform upgrade we'd already planned, not as a reason to upgrade."

Framing:

• Cost: zero license cost; the real cost is a bounded internal ownership commitment (pinned versions, one named maintainer, willingness to fork) plus a runtime upgrade that is now a precondition rather than a side effect.
• What changed: v5.0.0 dropped support for everything below Symfony 8 / PHP 8.5. Teams on older stacks must pin to 4.x. This is a deliberate signal about who the vendor is building for — their own stack — which is normal for internal-ecosystem glue, but it must be priced in.
• Benefit: faster service bootstrap, consistency with vendor-sanctioned patterns, fewer bespoke wiring decisions. A schedule and consistency win, not a capability win.
• Risk, stated plainly: 0 stars, 0 dependents, single-vendor authorship, and a now-demonstrated pattern of aggressive platform floors. No community upgrade path, no downstream-tested bug reports, no ecosystem of answers. Manageable — but it must be managed.
• Recommendation: approve for internal, Symfony-native, gdbots-aligned services only where the platform upgrade is already funded, behind a spike and a fork-and-own plan. Pin 4.x everywhere else with a recorded review date. Do not position it as a strategic dependency, and do not let it near a customer-facing launch blocker without an internal fallback.

To engineering (what they need to hear): v5 is a pure platform-floor bump — Symfony 8.x, PHP 8.5+. Read the source before adopting; confirm the Symfony/PHP matrix against your CI base images and host before committing. Decide explicitly between v5 and a 4.x pin, catalogue what the bundle registers, pin the version, and record both the version decision and the fork decision in an ADR so the next team doesn't re-litigate it from scratch.