[dakujem]

Raises the PHP upper bound in composer.json from <8.6 to <8.7, adds 8.6 to the unit test matrix and updates the PHP range in the README. Same changes as #83 made for 8.5.

PHP 8.6 GA is planned for 19 November 2026. With the current constraint, Composer refuses to install the package on PHP 8.6.

Tested locally on PHP 8.6.0RC6 (PHPUnit 11.5.57, without the redis, memcached and pcntl extensions and without database or Memcached services):

• 167 tests, 2435 assertions, no failures; 16 tests skipped for missing extensions.
• The Predis cases (DistributedMutex RedisMutex /w Predis) ran against a local Garnet 1.1.1 server instead of Redis. Garnet rejects PX values above 2147483647 ms, so for this run the expire cap in RedisMutex was lowered locally (not part of this PR).
• No deprecations from src/. php -l on 8.6 reports no compile-time deprecations in src/ or tests/.
• One deprecation from the dev dependency mikey179/vfsstream 1.6.12, triggered by MutexTest (FlockMutex cases): spl_object_hash() is deprecated since 8.6 (vfsStreamFile.php:374). Tracked in PHP 8.6 compatibility bovigo/vfsStream#299; the fixes are not released yet. Because the tests run with --fail-on-deprecation, the 8.6 jobs fail on this until vfsStream releases a fix.

CI notes:

• ghcr.io/mvorisek/image-php:8.6 is not published yet, so the 8.6 jobs cannot start until that image exists.
• Coverage (LOG_COVERAGE) stays on 8.5 for the same reason.

[mvorisek]

I plan to merge this when this is fully passing CI. As mentioned, vfs is not ready yet.

Until merged, you can use this HEAD commit of this PR branch in your composer.

[dakujem]

Good to know you are ready for the release. Thank you in advance.

[mvorisek]

The Predis cases (DistributedMutex RedisMutex /w Predis) ran against a local Garnet 1.1.1 server instead of Redis. Garnet rejects PX values above 2147483647 ms, so for this run the expire cap in RedisMutex was lowered locally (not part of this PR).

2147483647 equals to 2 147 483 seconds (24.86 days) only. Is there a workaround how to support longer TTL, like passing TTL in seconds?

[dakujem]

I'm not sure i follow your question. This was my local Windows setup with Garnet which i use as a RESP-compatible cache instead of Redis. It's wording from the agent that attempted to run the tests even though my env was not compatible, instead of skipping all the redis ones. As such, it's probably a question for the Garnet dev team.