Predis Release History

How Does Predis Handle Version Support?

Predis does not publish a formal support policy or fixed EOL dates like many large runtimes or frameworks.

The maintainers keep three major versions active in parallel through separate Git branches, following a community-driven, best-effort approach. The current stable major version receives the majority of new features, bug fixes, and improvements, while older majors continue to receive occasional maintenance depending on community needs and Redis/Valkey compatibility requirements.

In practice, most teams treat the latest major version as the actively developed one, with previous majors serving as longer-term options when upgrading requires more planning.

What Is the Support Situation for Different Predis Major Versions?

Predis maintains three major version lines simultaneously:

This model gives teams flexibility but means support intensity decreases as you move to older majors. The project focuses most effort on the current major while still addressing critical issues in older lines when they arise.

What Risks Come with Staying on Older Predis Versions?

Running an older major version of Predis mainly exposes you to missing newer Redis/Valkey protocol features (such as improved RESP3 support or cluster handling) and slower incorporation of performance improvements or bug fixes.

Because Predis is a pure-PHP client, compatibility issues usually appear as missing commands, different behavior with newer Redis features, or the need to update your Redis server version separately. In production environments with high traffic or complex cluster setups, teams often notice these gaps during Redis upgrades or when adding new features.

Most experienced PHP teams upgrade to the latest major within one or two release cycles of their application to avoid accumulating technical debt in the Redis layer.

What Happens When a Predis Major Version Ages?

When a major version becomes older, the maintainers shift focus to the newer line. Bug fixes and new Redis command support slow down significantly, though critical security-related issues may still receive attention depending on community contributions.

The older version continues to work with existing Redis servers it was designed for, but it will not automatically gain support for newer Redis/Valkey capabilities or protocol changes. Eventually, upgrading becomes necessary to keep using modern Redis features reliably.

In practice, many applications stay on the previous major for 12--24 months while planning the migration, especially when the upgrade involves PHP version changes or refactoring connection logic.

How Can You Check Which Predis Version Your Project Is Using?

The easiest way is through Composer:

composer show predis/predis

You can also check inside your code by inspecting the client object or looking at the composer.lock file for the exact version constraint.

Many teams add a simple health-check endpoint that logs the Predis version alongside the Redis server version to make monitoring easier across environments.