Quick changes from review

A few small adjustments based on tech review

Author: peachdawnleach

src/current/v25.3/upgrade-with-pcr.md

@@ -8,7 +8,7 @@ docs_area: manage
 When [**physical cluster replication (PCR)**]({% link {{ page.version.version }}/physical-cluster-replication-overview.md %}) is enabled, you must use the process on this page to upgrade your clusters. This process ensures that the standby cluster upgrades before the primary cluster.
 
 {{site.data.alerts.callout_info}}
-The entire standby cluster must be at the same version as, or one version ahead of, the primary's virtual cluster. Within the primary and standby CockroachDB clusters, the _system virtual cluster (SystemVC)_ must be at a cluster version greater than or equal to the _app virtual cluster (AppVC)_.
+The entire standby cluster must be on the same version as the primary cluster or a version the primary cluster can directly upgrade to. Within the primary and standby CockroachDB clusters, the _system virtual cluster (SystemVC)_ must be at a cluster version greater than or equal to the _app virtual cluster (AppVC)_.
 {{site.data.alerts.end}}
 
 ## Upgrade primary and standby clusters
@@ -27,9 +27,7 @@ To upgrade your primary and standby clusters:
     If you need to [roll back]({% link {{ page.version.version }}/upgrade-cockroach-version.md %}#roll-back-a-major-version-upgrade) an upgrade, you must do so before the upgrade has been finalized.
     {{site.data.alerts.end}}
 
-1. If auto-finalization is disabled, [finalize]({% link {{ page.version.version }}/upgrade-cockroach-version.md %}#finalize-a-major-version-upgrade-manually) the upgrade on the standby cluster's AppVC.
-
-    After you have finalized the upgrade on the standby cluster's AppVC, the clusters can remain in this state for an indefinite amount of time. You can wait to upgrade the primary cluster as long as is needed.
+    After you have finalized the upgrade on the standby cluster's SystemVC, the clusters can remain in this state for an indefinite amount of time. You can wait to upgrade the primary cluster as long as is needed.
 
 1. [Upgrade the binaries]({% link {{ page.version.version }}/upgrade-cockroach-version.md %}#perform-a-major-version-upgrade) on the primary cluster. Replace the binary on each node of the cluster and restart the node.
 
@@ -38,16 +36,18 @@ To upgrade your primary and standby clusters:
 1. If auto-finalization is disabled, [finalize]({% link {{ page.version.version }}/upgrade-cockroach-version.md %}#finalize-a-major-version-upgrade-manually) the upgrade on the primary cluster's SystemVC. 
 
     {{site.data.alerts.callout_info}}
-    If you need to [roll back]({% link {{ page.version.version }}/upgrade-cockroach-version.md %}#roll-back-a-major-version-upgrade) an upgrade, you must do so before the upgrade has been finalized.
+    If you need to [roll back]({% link {{ page.version.version }}/upgrade-cockroach-version.md %}#roll-back-a-major-version-upgrade) an upgrade, you must do so before the upgrade has been finalized. Rolling back the upgrade on the primary cluster does not also roll back the standby cluster.
     {{site.data.alerts.end}}
 
-1. If auto-finalization is disabled, [finalize]({% link {{ page.version.version }}/upgrade-cockroach-version.md %}#finalize-a-major-version-upgrade-manually) the upgrade on the primary cluster's AppVC.
+1. If auto-finalization is disabled, [finalize]({% link {{ page.version.version }}/upgrade-cockroach-version.md %}#finalize-a-major-version-upgrade-manually) the upgrade on the primary cluster's AppVC. 
+
+    Upgrading the primary cluster's AppVC also upgrades the standby cluster's AppVC, since it replicates from the primary.
 
 ## Upgrade ReaderVC
 
 If you have a [_reader virtual cluster (ReaderVC)_]({% link {{ page.version.version }}/read-from-standby.md %}), use the following steps to upgrade it by dropping and re-creating it:
 
-1. After upgrading the AppVCs on your primary and standby clusters, wait for the replicated time to pass the time at which the upgrade completed.
+1. After upgrading the AppVC on your primary cluster, wait for the replicated time to pass the time at which the upgrade completed.
 1. On the standby cluster, stop the ReaderVC service:
 
     {% include_cached copy-clipboard.html %}
@@ -62,13 +62,6 @@ If you have a [_reader virtual cluster (ReaderVC)_]({% link {{ page.version.vers
     DROP VIRTUAL CLUSTER <readervc-name>
     ~~~
 
-1. On the AppVC, double-check that the standby cluster's AppVC has upgraded:
-    
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    SHOW CLUSTER SETTING version
-    ~~~
-
 1. Back on the standby cluster, if the version is as expected, re-create the ReaderVC:
 
     {% include_cached copy-clipboard.html %}
@@ -82,6 +75,6 @@ If you need to perform a [failover]({% link {{ page.version.version }}/failover-
 
 However, after performing a failover you cannot perform a [fast failback]({% link {{ page.version.version }}/failover-replication.md %}#failback) to the original primary cluster during the upgrade process. This is because at times during the upgrade the standby cluster is ahead of the primary cluster.
 
-## Patch deferrals
+## Minor version upgrades
 
-Patch versions are not relevant when determining PCR compatibility. There is no need to consider PCR compatibility when upgrading to a specific patch version within a major version.
+Minor versions are not relevant when determining PCR compatibility. There is no need to consider PCR compatibility when upgrading to a specific minor version within a major version.