frappe-upgradelisted

# Migrations, Patches & Upgrades ## Usage Use this skill when: - Writing a patch (data backfill, field rename, cleanup) or editing patches.txt - Understanding what `bench migrate` runs and in what order - Planning a major version upgrade (v14 → v15 → v16) - Recovering from failed patches or wrong app-uninstall order ## What `bench migrate` actually runs (in order) 1. `before_migrate` hooks 2. **`[pre_model_sync]` patches** — run against the OLD schema 3. **Model sync** — DocType JSON files → database schema 4. **`[post_model_sync]` patches** — run against the NEW schema 5. Fixture sync, dashboards, customizations, translations 6. `after_migrate` hooks This ordering decides where your patch goes: reading/writing fields that the new code REMOVES → pre; backfilling fields the new code ADDS → post. ## patches.txt ``` [pre_model_sync] myapp.patches.v1_1.capture_legacy_status_before_field_removal [post_model_sync] myapp.patches.v1_1.backfill_new_status_field myapp.patches.v1_2.rename_warehouse_field ``` **All-or-nothing rule:** either every patch line sits under a section header, or the file has NO headers at all (legacy format — everything runs pre-model-sync). A line above the first header makes the parser fall back to legacy mode for the **whole file**, silently turning your `[post_model_sync]` patches into pre-sync ones. Two more line forms the parser accepts: `execute:frappe.db.set_value(...)` (inline one-liner, no patch file) and a `finally:` prefix (queues the pat