Phpredis Bundle Laravel Package

Product Decisions This Supports

• Correcting the record before anything else. The package is described as "phpredis for symfony2 apps" — it is a Symfony 2 bundle, not a Laravel package. The Laravel-oriented integration notes supplied alongside it (service providers, vendor:publish, bootstrap/app.php) describe a generic Laravel library and are not evidence about this repository. Any decision must be made against the Symfony DI facts, not that boilerplate. Flag this upward: it is a sourcing/evidence problem, not just a naming one.
• Build vs. buy, where "buy" is already lost. The bundle's entire value is ~40 lines of YAML/DI glue that registers \Redis connections as container services. That is a one-to-two-day in-house build on any supported Symfony version. Buying it means buying a dependency last released in November 2014 — eleven years of unpatched code — to avoid writing a service definition. Buy loses decisively here.
• Roadmap gating. The realistic question is not "should we adopt this?" but "is anything in our estate still pinned to Symfony 2, and what blocks the upgrade?" Symfony 2 reached end of life in 2016 (2.8 in 2018); Symfony 3, 4, 5, 6 and 7 have shipped since. A 2014 bundle cannot be a reason to defer that migration — it should be on the exit checklist, replaced as part of the upgrade rather than carried through it.
• Use-case scoping. If the need is Redis for caching, sessions, or queues, the maintained answers are Symfony's own Cache Redis adapter, the Messenger Redis transport, or a current bundle. The phpredis C extension itself remains an excellent choice; the bundle wrapper around it is the obsolete part. Decide the transport, not the wrapper, and keep the extension.
• Sunset and decision-log hygiene. Record an explicit "rejected with reason" entry. Zero stars, a 0.3 quality score, and a decade of silence are not ambiguous signals, and a written rationale prevents the same package resurfacing in a future audit as an unexplained gap.

When to Consider This Package

Consider it only if all of the following hold:

• The application is a Symfony 2.x codebase still in production, running PHP 5.x/7.0, with no funded upgrade path in the current planning horizon.
• You need multiple named phpredis connections declared in YAML and injected into services, and writing that config yourself is genuinely out of scope for the team.
• The stack is frozen: no new features, no PHP version bumps, no compliance or security-certification requirement that mandates current, supported dependencies.

Look elsewhere — in practice, almost always:

• Any Symfony 3.4+ or PHP 7.4+/8.x target. The bundle predates all of it; compatibility is unverified and the 1.0.2 release is the last artefact that exists.
• New projects, or any product with a roadmap beyond maintenance. Adopting an unmaintained 2014 dependency is a decision you will have to reverse later at higher cost.
• Security, audit, or regulated environments. No security disclosure process, no maintainer activity, no patch cadence. MIT licensing means you could fork and maintain it — but then you own it, and owning it is strictly worse than the 40-line build.
• Teams without resident Symfony 2 expertise. If nobody on the team can read the bundle's DI compiler passes, you cannot assess or fork it, and troubleshooting falls to a dead GitHub issue tracker.
• Any need beyond a raw client — session handlers, cache pools, queue consumers. Those are exactly where maintained integrations have moved on and this one has not.

How to Pitch It (Stakeholders)

For executives — one paragraph: A dependency under consideration was last released in November 2014, has zero community traction, and targets Symfony 2, a framework version that has been end-of-life for roughly eight years. It does one small thing: it lets teams declare Redis connection settings in configuration instead of code. Replicating that in-house is a day or two of work. The decision is therefore low-cost and low-drama — we should decline adoption, record why, and if any part of the estate still depends on it, treat that as a marker on the Symfony upgrade backlog rather than a reason to keep the stack frozen.

For engineering leads — the ask:

• Do not adopt. Replace with a small in-house service definition against phpredis, or a currently maintained Redis integration on a supported Symfony version.
• Budget: one to two days engineering to replicate the functionality, plus whatever the underlying Symfony upgrade already costs. No new vendor relationship, no licence review, no procurement.
• If a legacy Symfony 2 app must keep it temporarily: pin ^1.0 (1.0.2 is the only release with a correct exception class name), wrap the client behind your own interface so call sites do not reference the bundle, and log it as technical debt with a named owner and a target removal date.
• Risk posture: the risk here is not that the package breaks tomorrow — it is that it cannot be fixed tomorrow. No patch will arrive for a PHP 8 incompatibility, a CVE in the surrounding chain, or a behavioural surprise. That is unacceptable for anything customer-facing and tolerable only inside a frozen legacy scope.
• What we need from the business: confirmation that no new work is planned on the Symfony 2 surface. If new work is planned, the honest framing is that the bundle is a symptom and the framework upgrade is the actual decision in front of us.