Merge pull request #6271 from EnterpriseDB/dev/pgd-upgrade-tweak

Tweak upgrade warning for clarity, update version number in example.

product_docs/docs/pgd/5.6/upgrades/manual_overview.mdx

@@ -37,9 +37,9 @@ You can use both of these approaches in a rolling manner.
 ### Rolling upgrade considerations
 
 While the cluster is going through a rolling upgrade, mixed versions of software
-are running in the cluster. For example, suppose nodeA has PGD 3.7.16, while
-nodeB and nodeC have 4.1.0. In this state, the replication and group
-management uses the protocol and features from the oldest version (3.7.16
+are running in the cluster. For example, suppose nodeA has PGD 4.3.6, while
+nodeB and nodeC have 5.6.1. In this state, the replication and group
+management uses the protocol and features from the oldest version (4.3.6
 in this example), so any new features provided by the newer version
 that require changes in the protocol are disabled. Once all nodes are
 upgraded to the same version, the new features are enabled.

product_docs/docs/pgd/5.6/upgrades/tpa_overview.mdx

@@ -13,7 +13,7 @@ If you used TPA to install your cluster, you can also use TPA to upgrade it. The
 You can read more about the capabilities of TPA upgrades in [Upgrading your cluster](/tpa/latest/tpaexec-upgrade/) in the TPA documentation.
 
 !!! Warning Always test first
-If possible, always test upgrade processes in a QA environment first. This helps to ensure that there are no unexpected factors to take into account. TPA's ability to reproducibly deploy a PGD configuration makes it much easier to build a test environment to work with.
+Always test upgrade processes in a QA environment first. This helps to ensure that there are no unexpected factors to take into account. TPA's ability to reproducibly deploy a PGD configuration makes it much easier to build a test environment to work with.
 !!!
 
 ## Minor and major PGD upgrades

product_docs/docs/pgd/5/upgrades/manual_overview.mdx

@@ -37,9 +37,9 @@ You can use both of these approaches in a rolling manner.
 ### Rolling upgrade considerations
 
 While the cluster is going through a rolling upgrade, mixed versions of software
-are running in the cluster. For example, suppose nodeA has PGD 3.7.16, while
-nodeB and nodeC have 4.1.0. In this state, the replication and group
-management uses the protocol and features from the oldest version (3.7.16
+are running in the cluster. For example, suppose nodeA has PGD 4.3.6, while
+nodeB and nodeC have 5.5.1. In this state, the replication and group
+management uses the protocol and features from the oldest version (4.3.6
 in this example), so any new features provided by the newer version
 that require changes in the protocol are disabled. Once all nodes are
 upgraded to the same version, the new features are enabled.

product_docs/docs/pgd/5/upgrades/tpa_overview.mdx

@@ -13,7 +13,7 @@ If you used TPA to install your cluster, you can also use TPA to upgrade it. The
 You can read more about the capabilities of TPA upgrades in [Upgrading your cluster](/tpa/latest/tpaexec-upgrade/) in the TPA documentation.
 
 !!! Warning Always test first
-If possible, always test upgrade processes in a QA environment first. This helps to ensure that there are no unexpected factors to take into account. TPA's ability to reproducibly deploy a PGD configuration makes it much easier to build a test environment to work with.
+Always test upgrade processes in a QA environment first. This helps to ensure that there are no unexpected factors to take into account. TPA's ability to reproducibly deploy a PGD configuration makes it much easier to build a test environment to work with.
 !!!
 
 ## Minor and major PGD upgrades