• v1.2.3 e968cfdbca

    Ghost released this 2025-09-30 13:39:33 -04:00 | 401 commits to main since this release

    Summary

    Fixes staging deployment by renumbering migrations to match what staging
    has already applied.

    Problem

    Staging already applied migration 008 (metadata separation) before we
    inserted the new cleanup migration. When we added the cleanup as 008 and
    renumbered metadata to 009, staging tried to apply 009 again and failed
    with "column already exists".

    Current State

    • Staging: Has run original 008 (metadata separation), marked as
      complete. Failed trying to run 009 (which is the same migration
      renumbered).
    • Production: Has not run either 008 or 009 yet.

    Solution

    • Rename 008_clean_invalid_data.sql → 007a_clean_invalid_data.sql
    • Rename 009_separate_official_metadata.sql →
      008_separate_official_metadata.sql (back to original)

    How This Fixes It

    With this renumbering:

    1. Staging behavior:
    • Sees 008 is already complete (the metadata migration it already ran)
    • Sees 007a as new and runs it, but it will be a no-op (skips because
      staging doesn't have the problematic production data)
      • Continues normally
    1. Production behavior:
      • Runs 007a (cleanup migration) - removes invalid data
    • Runs 008 (metadata separation) - applies successfully because data is
      now clean
      • Both migrations run in the correct order as intended

    Testing

    • Verified migration order works correctly
    • Tested on empty database (test environment) - 007a skips as expected
    • Tested with production data snapshot - 007a cleans data, 008 applies
      successfully

    This is a critical fix to unblock staging deployment.

    Downloads