This release removes the original classic queue storage implementation these days
known as CQv1. A 2nd generation implementation called CQv2 has been adopted
as the default starting with `4.2.0`.
This means that attemptes to declare a queue using the following [optional queue arguments](https://www.rabbitmq.com/docs/queues#optional-arguments) will fail:
*`x-queue-mode` set to any value
*`x-queue-version` set to `1`
Existing classic queues upgraded to CQv2 during an earlier upgrade to `4.2.x` will continue
See the [Upgrading guide](https://www.rabbitmq.com/docs/upgrade) for documentation on upgrades and [GitHub releases](https://github.com/rabbitmq/rabbitmq-server/releases)
All feature flags introduced in `4.2.0` and earlier are required, including the following:
*`rabbitmq_4.2.0`
*`rabbitmq_4.1.0`
*`rabbitmq_4.0.0`
*`khepri_db`
*`quorum_queue_non_voters`
*`message_containers_deaths_v2`
Enable all required feature flags before upgrading to `4.3.0`.
If your RabbitMQ cluster had plugin `rabbitmq_amqp1_0` enabled in RabbitMQ `3.13.x` (and your cluster still serves AMQP 1.0 client connections in `4.x`), your cluster should do at least one rolling update **after** enabling feature flag `rabbitmq_4.0.0` but **before** upgrading to `4.3.0`.
### Deprecated Features
In `4.3.0` the deprecation phase of the following features advanced from `permitted_by_default` to `denied_by_default`:
*`amqp_filter_set_bug`
### Mixed version cluster compatibility
RabbitMQ 4.3.0 nodes can run alongside `4.2.x`.
Mixed version clusters are a mechanism that allows rolling upgrade and are not meant to be run for extended
periods of time (no more than a few hours).
### Recommended Post-upgrade Procedures
This version does not require any additional post-upgrade procedures
* The HTTP Auth Backend can now optionally provide a custom authorization denial reason to AMQP clients.
To opt in, return `deny <Reason>` (instead of only `deny`) in the HTTP response body of your HTTP auth backend and set the following in your `rabbitmq.conf` file:
