--- a/install/schemas/upgrade/migration/1.0-1.1.php	Tue Feb 12 07:38:52 2008 -0500
+++ b/install/schemas/upgrade/migration/1.0-1.1.php	Tue Feb 12 07:44:16 2008 -0500
@@ -37,7 +37,13 @@
   $lang_local->import($lang_dir . "user.json");
   $lang_local->import($lang_dir . "admin.json");
   
-  setConfig('enano_version', installer_enano_version());
+  // This doesn't set to installer_enano_version() because it only
+  // migrates the database from 1.0.x to 1.1.x status and runs the
+  // core logic required to transform a 1.0.x installation into
+  // a 1.1.x installation. Thus, when upgrading, the upgrade script
+  // still needs to run all later upgrade schema files in addition
+  // to this migration code.
+  setConfig('enano_version', '1.1.1');
   
   return true;
 }

--- a/install/upgrade.php	Tue Feb 12 07:38:52 2008 -0500
+++ b/install/upgrade.php	Tue Feb 12 07:44:16 2008 -0500
@@ -234,6 +234,19 @@
       if ( !$db->sql_query($sql) )
         $db->_die();
     }
+    
+    // Is there an additional script (logic) to be run after the schema?
+    $postscript = ENANO_ROOT . "/install/schemas/upgrade/{$verset[0]}-{$verset[1]}.php";
+    if ( file_exists($postscript) )
+      @include($postscript);
+    
+    // The advantage of calling setConfig on the system version here?
+    // Simple. If the upgrade fails, it will pick up from the last
+    // version, not try to start again from the beginning. This will
+    // still cause errors in most cases though. Eventually we probably
+    // need some sort of query-numbering system that tracks in-progress
+    // upgrades.
+    
     setConfig('enano_version', $verset[1]);
   }
   echo '<p>All done!</p>';