History of Bitweaver upgrade process
<p>Key principle: <strong>Schema first, code second — always</strong></p>
<pre>
<code>1. Write upgrade file (schema changes only)
2. Test on development via installer
3. Verify installer shows correct version before AND after
4. Deploy upgrade file to production
5. Run installer upgrade on production
6. THEN deploy code that uses the new schema
7. Never edit a released upgrade file — create a new version (5.0.1 → 5.0.2)</code></pre>
<p><strong>Common pitfalls:</strong></p>
<ul>
<li>Firebird table names — never quote identifiers or they stay lowercase and need quoting everywhere</li>
<li>Code referencing new columns must never reach production before the upgrade runs</li>
<li>CC will try to skip steps — hold the line on the order</li>
</ul>
<p><strong>Version tracking:</strong></p>
<ul>
<li><code>kernel_config</code> stores package schema versions</li>
<li><code>schema_inc.php</code> defines target version</li>
<li>Installer compares the two and runs upgrade files in sequence</li>
</ul>
<pre>
<code>1. Write upgrade file (schema changes only)
2. Test on development via installer
3. Verify installer shows correct version before AND after
4. Deploy upgrade file to production
5. Run installer upgrade on production
6. THEN deploy code that uses the new schema
7. Never edit a released upgrade file — create a new version (5.0.1 → 5.0.2)</code></pre>
<p><strong>Common pitfalls:</strong></p>
<ul>
<li>Firebird table names — never quote identifiers or they stay lowercase and need quoting everywhere</li>
<li>Code referencing new columns must never reach production before the upgrade runs</li>
<li>CC will try to skip steps — hold the line on the order</li>
</ul>
<p><strong>Version tracking:</strong></p>
<ul>
<li><code>kernel_config</code> stores package schema versions</li>
<li><code>schema_inc.php</code> defines target version</li>
<li>Installer compares the two and runs upgrade files in sequence</li>
</ul>
