(NFC) DispatchPolicy - Add comments to docblock

This updates some of the docblocks to reflect https://github.com/civicrm/civicrm-core/pull/17126

diff --git a/CRM/Upgrade/DispatchPolicy.php b/CRM/Upgrade/DispatchPolicy.php
index de0fa72511d554bb988d2100a4ea0eeae97f93d9..1d214c25b5785ac622e1208f608cfd4134d203a1 100644 (file)
--- a/CRM/Upgrade/DispatchPolicy.php
+++ b/CRM/Upgrade/DispatchPolicy.php
@@ -30,6 +30,7 @@ class CRM_Upgrade_DispatchPolicy {
     // mixed: it depends on the specific hook and the specific upgrade-step.
     //
     // Some example considerations:
+    //
     // - If the "log_civicrm_*" tables and triggers are to be reconciled during
     //   the upgrade, then one probably needs access to the list of tables and
     //   triggers defined by extensions. These are provided by hooks.
@@ -47,7 +48,18 @@ class CRM_Upgrade_DispatchPolicy {
     //   they probably are not intended to fire during DB upgrade. Then again,
     //   upgrade-logic is usually written with lower-level semantics that avoid firing hooks.
     //
+    // To balance these mixed considerations, the upgrade runs in two phases:
+    //
+    // - Defensive/conservative/closed phase ("upgrade.main"): Likely mismatch
+    //   between schema+code. Low-confidence in most services (APIs/hooks/etc).
+    //   Ignore caches/indices/etc. Only perform low-level schema revisions.
+    // - Constructive/liberal/open phase ("upgrade.finish"): Schema+code match.
+    //   Higher confidence in most services (APIs/hooks/etc).
+    //   Rehydrate caches/indices/etc.
+    //
     // Related discussions:
+    //
+    // - https://github.com/civicrm/civicrm-core/pull/17126
     // - https://github.com/civicrm/civicrm-core/pull/13551
     // - https://lab.civicrm.org/dev/core/issues/1449
     // - https://lab.civicrm.org/dev/core/issues/1460