CQv2 upgrade recommendations for 3.13

Author: michaelklishin

release-notes/3.13.0.md

@@ -64,6 +64,20 @@ Once all nodes are upgraded to 3.13.0, these irregularities will go away.
 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
+
+#### Switch Classic Queues to CQv2
+
+We recommend switching classic queues to CQv2 after **all cluster nodes** have been upgrades,
+at first using policies, and then eventually using a setting in `rabbitmq.conf`. Upgrading
+classic queues to CQv2 at boot time using the configuration file setting can be
+potentially unsafe in environments where deprecated classic mirrored queues still exist.
+
+For new clusters, adopting CQv2 from the start is highly recommended:
+
+``` ini
+classic_queue.default_version = 2
+```
 
 
 ## Compatibility Notes
@@ -245,6 +259,19 @@ Release notes are kept under [rabbitmq-server/release-notes](https://github.com/
 
    GitHub issue: [#9797](https://github.com/rabbitmq/rabbitmq-server/pull/9797)
 
+ * Classic queue storage v2 (CQv2) has matured and is now recommended for all users.
+
+   We recommend switching classic queues to CQv2 after **all cluster nodes** have been upgrades,
+   at first using policies, and then eventually using a setting in `rabbitmq.conf`. Upgrading
+   classic queues to CQv2 at boot time using the configuration file setting can be
+   potentially unsafe in environments where deprecated classic mirrored queues still exist.
+
+   For new clusters, adopt CQv2 from the start by setting `classic_queue.default_version` in `rabbitmq.conf`:
+
+   ``` ini
+   classic_queue.default_version = 2
+   ```
+
  * Non-mirrored classic queues: optimizations of storage for larger (greater than 4 kiB) messages.
 
    GitHub issue: [#6090](https://github.com/rabbitmq/rabbitmq-server/pull/6090), [#8507](https://github.com/rabbitmq/rabbitmq-server/pull/8507)