(dev/core#1846) Container, ClassLoader Caches - Separate caches by version number

Before
------

If you load a new version of the CiviCRM codebase, then a freshness check
should cause the container cache to reset automatically (based on the fact
that various files have new timestamps).

However, it's possible that some kind of bug or omission prevents this from working.
Many developers won't notice such a bug because they're obsessive-compulsive
about clearing caches anyway.

After
-----

If you load a new version of the CiviCRM codebase, then it should use a new
container cache - regardless of how well the freshness check works.

diff --git a/CRM/Core/Config/Runtime.php b/CRM/Core/Config/Runtime.php
index 7e927af94f5d7d6da5212be6bcb2a6699b9f99e6..1fd76d270dc1bf760d9c8a1f4af51569348649ab 100644 (file)
--- a/CRM/Core/Config/Runtime.php
+++ b/CRM/Core/Config/Runtime.php
@@ -141,6 +141,14 @@ class CRM_Core_Config_Runtime extends CRM_Core_Config_MagicMerge {
         defined('CIVICRM_DOMAIN_ID') ? CIVICRM_DOMAIN_ID : 1,
         // e.g. one codebase, multi database
         parse_url(CIVICRM_DSN, PHP_URL_PATH),
+
+        // e.g. when you load a new version of the codebase, use different caches
+        // Note: in principle, the version number is just a proxy for a dozen other signals (new versions of file A, B, C).
+        // Proper caches should reset whenever the underlying signal (file A, B, or C) changes. However, bugs in this
+        // behavior often go un-detected during dev/test. Including the software-version basically mitigates the problem
+        // for sysadmin-workflows - so that such bugs should only impact developer-workflows.
+        \CRM_Utils_System::version(),
+
         // e.g. CMS vs extern vs installer
         \CRM_Utils_Array::value('SCRIPT_FILENAME', $_SERVER, ''),
         // e.g. name-based vhosts