Skip to content

5.1.0: deprecate APIs that change in 6.0 - #156

Open
tomaj wants to merge 1 commit into
5.xfrom
deprecations-5.1
Open

tomaj wants to merge 1 commit into
5.xfrom
deprecations-5.1

Conversation

@tomaj

@tomaj tomaj commented Oct 19, 2026 •

Copy link
Copy Markdown
Owner

Closes #90

Adds 5.1.0 to the new 5.x branch, which I created from tag 5.0.0 (ca91b4a). 5.1.0 changes no behaviour unless you opt in. It reports code that 6.0 will treat differently as E_USER_DEPRECATED notices. No tag has been created.

What is reported

  • Final classes. Extending a class that is final in 6.0 is reported: Dispatcher, Emitter, Message, the drivers and the shutdowns. They also get a @final since 5.1 annotation, so static analysers flag it as well.
  • Shutdown types. A shutdown whose shouldShutdown() or shutdown() takes DateTime is reported, because 6.0 passes DateTimeInterface. The check runs both in the Dispatcher constructor and in ShutdownTrait::setShutdown.
  • Priority order. A Redis/Predis priority order that 6.0 polls differently is reported (6.0 polls the highest number first).
  • Retries:
    • A handler that is retried only because it has canRetry()/maxRetry() is reported.
    • So is a RetryTrait user that overrides canRetry(), because 6.0 calls it and can skip the retry.
  • RabbitMQ durability. Creating LazyRabbitMqDriver without the new $durable argument is reported.

Opt-in 6.0 behaviour

  • RetryableHandlerInterface has the 6.0 signature. Handlers that implement it follow the 6.0 retry rules now.
  • RetryTrait::canRetry() accepts the optional $message and $exception arguments.
  • LazyRabbitMqDriver(..., bool $durable = false): true declares a durable queue and publishes persistent messages. An explicit delivery_mode still wins.

6.0 changes that cannot be deprecated

5.x can't detect these, or can't offer the new behaviour without breaking the old one. They are listed in the CHANGELOG:

  • RabbitMQ ack after handling
  • SQS delete after handling
  • Throwable catching, and driver errors being rethrown
  • Log and serializer exception texts
  • Microsecond shutdown timestamps and the handling of a shutdown time in the future
  • Tracy moving to suggest
  • PHP 8.4, psr/log and predis requirements
  • readonly properties and never return types
  • Redis ordering, beyond the priority-order notice

Decisions

  • Notices are silenced with @trigger_error (the Symfony convention). They reach deprecation collectors (PHPUnit, Symfony ErrorHandler, a custom handler) without spamming production logs.
  • CHANGELOG headings. The tagged 5.0.0 notes sat under [Unreleased]. I renamed that section to 5.0.0 - 2025-11-19 (the tag date) and added 5.1.0 - unreleased above it. The empty [Unreleased] section stays for work after 5.1.
  • Anonymous class names. Deprecation::name() strips the NUL suffix from them, because PHP 7.4's trigger_error cuts the message at the NUL.
  • Follow-up on master. UPGRADE-6.0.md on master says "None of these changes has a deprecation notice in 5.x: there is no 5.x maintenance branch". That sentence will be wrong once 5.1 is released, and should be updated on master at that point. This PR doesn't touch it.

Review fixes (this round)

  • Tests for a handler that has only canRetry() or only maxRetry() (no retry, no notice), so Infection kills the && → || mutant on the legacy retry gate in Dispatcher.
  • Empty CHANGELOG ## [Unreleased][unreleased] heading cleaned to ## [Unreleased] (the [unreleased] link target was missing).

Verification

  • PHP 8.4: 103 tests OK. PHP 7.4 (php:7.4-cli docker, earlier round): 101 tests OK before the two new cases, with 13 skipped because the redis extension is missing; the new cases do not need redis.
  • PHPStan is clean under 7.4. phpcs PSR2 is clean (line-length warnings in the new test file only).
  • Infection on the changed lines and new files: 100% MSI (Deprecation, RetryableHandlerInterface, RetryTrait, ShutdownTrait, and the new/changed lines in Dispatcher and LazyRabbitMqDriver). Re-run in a scratch copy with infection 0.29 (phpstan 0.12 removed there because of a php-parser conflict; strict covers checks turned off). Pre-existing uncovered code in Redis/Predis/Rabbit wait() loops is unchanged and out of scope. The branch's composer.json is unchanged for infection.

Docs

  • The README retry example now implements RetryableHandlerInterface, and a short "Preparing for 6.0" section points to the CHANGELOG.
  • examples/rabbitmq passes $durable = false explicitly, so it creates the same queue as before and raises no notice.

CI fixes for 5.x (the base branch was already red)

  • PHP 7.4 / 8.0:
    • Composer 2.9+ blocks package versions with security advisories, and every aws/aws-sdk-php release that still supports PHP < 8.1 carries two of them. As a result, composer install could not resolve.
    • composer.json now ignores exactly those two advisories in config.audit.ignore: PKSA-4t1p-xpk2-nsss (CloudFront signed policies) and PKSA-dxyf-6n16-t87m (S3 encryption client). Hermes uses neither, and the fixes need PHP 8.1.
    • This affects only this repo's dev installs. Projects that use Hermes resolve and audit their own dependencies.
  • PHPStan (8.1 job): on PHP 8.x Composer picks php-amqplib 2.10.1, which has no AMQPConnectionBlockedException. The @throws of LazyRabbitMqDriver::send() now names the parent AMQPRuntimeException, which covers the closed and blocked exceptions in every 2.x version.
  • PHPUnit (risky tests): forceCoversAnnotation / beStrictAboutCoversAnnotation stayed on for the suite; DeprecationTest lists the classes it covers so PHPUnit does not mark it risky.

Milestone

Assigned to milestone 6.0.0 (there is no 5.1.0 milestone). Tag 5.1.0 on the 5.x branch after merge is a separate step.

@tomaj tomaj added this to the 6.0.0 milestone Oct 19, 2026
@tomaj tomaj self-assigned this Oct 19, 2026
@tomaj
tomaj force-pushed the deprecations-5.1 branch 2 times, most recently from 5e86fed to de9621d Compare October 22, 2026 09:25

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant